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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://pgfoundry.org/mailman/listinfo/pgpool-hackers
find_primary_node.patch
Description: Binary data
_______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
