[Pgpool-hackers] path to follow master after a failover

Tatsuo Ishii ishii at sraoss.co.jp
Mon Jan 31 00:02:52 UTC 2011


>> Thanks. I will look into the patch to understand your idea/design
>> rather the code itself because this has a large impact on pgpool-II's
>> overall design.
> 
> Just to let you know that the patch itself doesn't affect the overall
> design of PgPool. This was exactly what I want : not modify anything in
> the way it actually works to not break anything and easy adoption of the
> patch.
> 
>>  Also we need to look at PostgreSQL 9.1 development
>> cycle. It may affect the design of the patch (we want to effectively
>> use PostgreSQL features but in the same time we don't want to break
>> the compatibility to existing PostgreSQL releases).
> 
> I don't see what's in Pg 9.1 can affect the patch unless there's a plan
> for cascading replication but I don't think so.  Also we will not break
> any PostgreSQL compatibility if this patch only affect streaming
> replication, isn't it ?
> 
>>  So I want to take enough time to review your patch.
> 
> Yes, no problem I've sent a lot of patches these last weeks and I know
> that review can takes more time than coding.
> 
>> In the mean time I suggest you to test your patches in other than
>> streaming replication mode to make sure it does not break them.
> 
> Ok, I will do the work for this patch as well as the promote any node as
> master patch.  Do you think this last one may be useful in other mode
> than streaming replication ?
> 
> Whatever we can discuss all of that in Paris next week, I will be very
> pleased to meet you.

Last weekend I have some time to review your patches.

I think the basic design of the patches is good.

- It seems the patch degenerates standbys even if not in streaming
  replication mode. I don't think it's a good idea to do it in the
  replication mode or raw mode. Not sure for slony mode.

- IMO we need finer control over which node should be
  degenerated. Probably we should have a new flag for each
  backend something like this:

  backend_option0 = opt_value where opt_value is one of:

  DEGENRATE_IF_NEEDED: degenrate whenever pgpool-II thinks
  needed. This is same behavior of 3.0 or before.

  NEVER_DEGENRATE: never degerate this node.

  DEGENERATE_IF_NOT_PROMOTED: in the master/slave mode, degenrate the
  if it's not chosen as NEVER_DEGENRATE: never degerate this nodethe promoting node.
  (I'm not sure this should apply to slony mode)

- myexit() should not be used in fork_follow_child.

BTW, why do you specify pgpool's IP address in your sample script? IMO
it's obvious that it is localhost.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp


More information about the Pgpool-hackers mailing list