[Pgpool-hackers] Follow master patch modified

[Tatsuo Ishii]

Just for memory...

I talked to Toshihiro about this patches.  Problem with this approach
is, if user does not want to promote a standby when the primary goes
down, pgpool-II waits for recovery_timeout seconds (without this
patch, pgpool-II immediately returns), which means failover process
takes for seconds from user's point of view. I'm afraid it's not
an acceptable behavior.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> Hi,
> 
> How about the attached prototype patch, about the solution of
> find_primary_node() problem?
> 
> This patch is simple design and small.
> 
> - Primary node is "SELECT pg_is_in_recovery()" = false,
>   Standby node is "SELECT pg_is_in_recovery()" = true.
> - Wait till a primary node appears when failover occurred.
> - Use recovery_timeout for timeout.
> 
> Any feedback will be appreciated.
> 
> -- 
> Toshihiro Kitagawa
> SRA OSS, Inc. Japan
> 
> On Wed, 30 Mar 2011 16:45:34 +0900
> Toshihiro Kitagawa <kitagawa at sraoss.co.jp> wrote:
> 
>> Hi,
>> 
>> I've revised Gilles's patch a little and committed it.
>> 
>> * Changes
>> 
>> - The degeneration nodes should not exclude the new master node,
>>   but the new primary node. Because the new master node is sometimes
>>   different from the new primary node.
>> 
>> - trigger_failover_command() should call before updating
>>   Req_info->master_node_id and Req_info->master_node_id,
>>   otherwise the function cannot get correct '%M'(old master node id)
>>   and '%P'(old primary node id).
>>   However, In this case that is using fork, the parent process might
>>   update them. So I added arguments of them to related functions.
>> 
>> - To fix find_primary_node() is still pending.
>>   I found a problem such as the following bug report:
>> 
>>   http://pgfoundry.org/pipermail/pgpool-hackers/2011-January/000525.html
>> 
>>   I did the testing in following sequences:
>> 
>>   precondition) failover_command setting is ''(empty string)
>>   1) node 0 down
>>   2) node 1 keeps hot standby without primary node
>> 
>>   At this time, the right pgpool's log message is:
>> 
>>      find_primary_node: no primary node found
>> 
>>   But not really:
>> 
>>      find_primary_node: primary node id is 1
>> 
>>   This means failure of the recognition of the primary node.
>>   We must fix this.
>> 
>> -- 
>> Toshihiro Kitagawa
>> SRA OSS, Inc. Japan
>> 
>> On Wed, 09 Mar 2011 09:49:49 +0100
>> Gilles Darold <gilles.darold at dalibo.com> wrote:
>> 
>> > Tatsuo,
>> > 
>> > Le 09/03/2011 08:43, Tatsuo Ishii a écrit :
>> > > I have applied this patches to the CVS HEAD and got an compile error:
>> > >
>> > > gcc -DHAVE_CONFIG_H -DDEFAULT_CONFIGDIR=\"/usr/local/etc\" -I.  -D_GNU_SOURCE -I /usr/local/pgsql/include   -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
>> > > main.c: In function ‘failover’:
>> > > main.c:1654: error: ‘POOL_REQUEST_INFO’ has no member named ‘prefered_primary_node_id’
>> > Oh yes, sorry this is a line from the promote patch, you can safely
>> > remove it. Or if you prefer I've attached the fixed patch.
>> > 
>> > > I thought I needed pcp_promote_node patch and tried to apply the patch but I got:
>> > >
>> > > $ patch -b -p1 < ../patch-promote.diff 
>> > > patching file main.c
>> > > Hunk #2 succeeded at 167 (offset 2 lines).
>> > > Hunk #4 succeeded at 1376 (offset 2 lines).
>> > > Hunk #6 FAILED at 1604.
>> > > Hunk #7 succeeded at 1660 with fuzz 2 (offset 44 lines).
>> > > Hunk #8 FAILED at 1686.
>> > > Hunk #9 FAILED at 2398.
>> > > Hunk #10 FAILED at 2412.
>> > > Hunk #11 FAILED at 2441.
>> > > 5 out of 11 hunks FAILED -- saving rejects to file main.c.rej
>> > > patching file pcp/Makefile.am
>> > > patching file pcp/Makefile.in
>> > > patching file pcp/pcp.c
>> > > patching file pcp/pcp.h
>> > > patching file pcp/pcp_promote_node.c
>> > > patching file pcp_child.c
>> > > patching file pool_auth.c
>> > > patching file pool.h
>> > > patching file pool_query_context.c
>> > >
>> > > Any help appreciated.
>> > Those 2 patches are working on same parts so hunks on main.c are normal,
>> > you have to applied by hand what have been rejected.
>> > 
>> > -- 
>> > Gilles Darold
>> > Administrateur de bases de données
>> > http://dalibo.com - http://dalibo.org
>> > 
>> 
>> _______________________________________________
>> Pgpool-hackers mailing list
>> Pgpool-hackers at pgfoundry.org
>> http://pgfoundry.org/mailman/listinfo/pgpool-hackers