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

[Tatsuo Ishii]

>>> 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.

One more comment. This patch automatically allows to resync
non-promoted standby. That's good. But it seems the standby does not
stop when follow master script executed. Is it required to invoke
pg_ctl in the script?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp