[pgpool-general: 26] Re: [Pgpool-general] pgpool limitations

[Sandeep Thakkar]

I just see some additional statements like "failback event found. restart myself"...

2011-11-30 10:39:46 LOG:   pid 7398: find_primary_node_repeatedly: waiting for finding a primary node
2011-11-30 10:39:46 LOG:   pid 7398: find_primary_node: primary node id is 1
2011-11-30 10:39:46 LOG:   pid 7398: failover: set new primary node: 1
2011-11-30 10:39:46 LOG:   pid 7398: failover: set new master node: 0
2011-11-30 10:39:46 LOG:   pid 7398: failback done. reconnect host localhost(5447)
2011-11-30 10:39:46 LOG:   pid 7532: worker process received restart request
2011-11-30 10:39:47 LOG:   pid 7565: pcp child process received restart request
2011-11-30 10:39:47 LOG:   pid 7398: worker child 7532 exits with status 256
2011-11-30 10:39:47 LOG:   pid 7398: fork a new worker child pid 7648
2011-11-30 10:44:10 LOG:   pid 7533: do_child: failback event found. restart myself.
2011-11-30 10:44:10 LOG:   pid 7534: do_child: failback event found. restart myself.
....
....

 


________________________________
 From: Tatsuo Ishii <ishii at postgresql.org>
To: sandeeptt at yahoo.com 
Cc: pgpool-general at pgpool.net 
Sent: Tuesday, November 29, 2011 3:24 PM
Subject: Re: [pgpool-general: 8] Re: [Pgpool-general] pgpool limitations
 
I can't think of any other reasons. Can you find anything special in
the pgpool log when pgpool child exits?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

> client_idle_limit is set to '0'. Here is the other related settings:
> ....
> pcp_timeout = 10
> num_init_children = 32
> max_pool = 4
> child_life_time = 300
> connection_life_time = 0
> child_max_connections = 0
> client_idle_limit = 0
> ....
>  
> 
> 
> ________________________________
>  From: Tatsuo Ishii <ishii at sraoss.co.jp>
> To: sandeeptt at yahoo.com 
> Cc: singh.gurjeet at gmail.com; pgpool-general at pgfoundry.org; pgpool-hackers at pgfoundry.org 
> Sent: Wednesday, November 23, 2011 8:21 PM
> Subject: Re: [Pgpool-general] pgpool limitations
>  
> One possibility is client_idle_limit.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
> 
>> I have found that sometimes the client connections get disconnected and the new ones are established. What I do is I get the PIDs using "pcp_proc_count" before running "pcp_attach_node" and then run "pcp_proc_count" to check if the PIDs remain same. I found that the behaviour is random. When can this happen?
>> 
>> 
>> ________________________________
>>  From: Tatsuo Ishii <ishii at sraoss.co.jp>
>> To: singh.gurjeet at gmail.com 
>> Cc: pgpool-general at pgfoundry.org; pgpool-hackers at pgfoundry.org 
>> Sent: Thursday, August 11, 2011 6:11 AM
>> Subject: Re: [Pgpool-general] pgpool limitations
>>  
>>>> > > Is there something in the works to enable this, or is this feature
>>>> still in
>>>> > > design phase? If it is already being/been developed, I wish to know if
>>>> this
>>>> > > can be back-patched to a point release of pgpool 3.0.x.
>>>> >
>>>> > It has been already in pgpool-II 3.1 alpha version.
>>>> > Currently there's no plan to back-patching to 3.0.x.
>>>>
>>>> I certainly hope we won't backpatch a new feature. That would be insane.
>>>>
>>> 
>>> I don't consider this a new feature. I'd say this is unexpected side-effect
>>> (a.k.a bug) of pcp_attach_node, since nowhere in the docs does is say that
>>> invoking pcp_attach_node would drop all client connections.
>> 
>> This behavior has not been changed since pcp_attach_node was born in
>> 2006. Moreover, the enhancement in 3.1 is only for steaming
>> replication mode. Other modes including replication mode does not take
>> advantage of this.
>> --
>> Tatsuo Ishii
>> SRA OSS, Inc. Japan
>> English: http://www.sraoss.co.jp/index_en.php
>> Japanese: http://www.sraoss.co.jp
>> _______________________________________________
>> Pgpool-general mailing list
>> Pgpool-general at pgfoundry.org
>> http://pgfoundry.org/mailman/listinfo/pgpool-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20111204/f9e00a36/attachment.html>