[pgpool-general: 4530] Re: Worker Processes Exit and Are Not Re-spawned

Mike Neir mike at liquidweb.com
Wed Mar 9 00:55:08 JST 2016


Muhammad,

Excellent news! Thank you for getting that corrected so quickly. Is there
any way of knowing how long it will take for that change to be reflected in
pgpool pacakge in the pgdg yum repositories, or is that out of the pgpool
developers' scope of influence?

MN


Mike Neir
Infrastructure Administrator
Liquid Web, Inc.

On Mon, Mar 7, 2016 at 10:47 AM, Muhammad Usama <m.usama at gmail.com> wrote:

> Hi Mike
>
> Thanks for pointing out this out,  The problem was caused by the logical
> mistake in the latest version of pgpool-II and I have pushed the fix for it.
>
>
> http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=e2f822fae9a4956f210bccafd0eade26642c90fa
>
> Regards
> Muhammad Usama
>
>
> On Sat, Mar 5, 2016 at 5:43 AM, Mike Neir <mike at liquidweb.com> wrote:
>
>> Greetings pgpool devs and users,
>>
>> I am attempting to re-create a postgres 9.2 + pgpool setup that a former
>> co-worker created so that I may become more familiar with the setup process
>> and so it can be properly documented. I am configuring a two-node test lab
>> using streaming replication, where the postgres WAL sender handles writes,
>> and both the WAL sender and receiver can handle reads.
>>
>> I believe I have everything configured properly except for one vexing
>> issue. When running queries through pgpool, even simple status queries, the
>> workers will eventually die, having reached their internal connection
>> limit. This is expected, but pgpool does not seem to be forking another
>> worker to replace it, and that behavior eventually results in pgpool not
>> being able to handle queries due to a lack of workers. This manifests in
>> the logs as follows:
>>
>> 2016-03-04 18:27:50: pid 8754: FATAL:  child exiting, 500 connections
>> reached
>> 2016-03-04 18:27:50: pid 8303: LOG:  child process with pid: 8754 exits
>> with status 512
>> 2016-03-04 18:27:50: pid 8303: LOG:  child process with pid: 8754 exited
>> with success and will not be restarted
>>
>> I have not yet got to the point of importing data into postgres. I can
>> manifest this condition with repeated execution of the following command:
>>  $ psql -h localhost -U monitor postgres -c "SHOW pool_nodes;"
>>
>> The behavior is the same on both nodes, regardless of whether it is a WAL
>> sender or recevier.
>>
>> I've attempted to dig through the sources to find the scenario that would
>> tell pgpool that not forking a replacement worker is proper behavior, but
>> my C is *very* rusty, and I ran out of patience long before I understood
>> what leads to that condition.
>>
>> In short, I'm looking for insight on what configuration directives could
>> lead to that behavior, and how to correct it.
>>
>> Environment Details:
>> - Each node is a VM running CentOS 6.7, 64-bit
>> - Each node is running postgres 9.2.15 (latest version available),
>> installed via pgdg92 yum repository
>> - Each node is running pgpool-II-92 3.5.0-1 (latest version available),
>> installed via pgdg92 yum repository
>> - I can provide the pgpool or postgres configurations if need be, but
>> since they are lengthy, I will wait until they're requested.
>>
>> Mike Neir
>> Infrastructure Administrator
>> Liquid Web, Inc.
>>
>>
>> _______________________________________________
>> pgpool-general mailing list
>> pgpool-general at pgpool.net
>> http://www.pgpool.net/mailman/listinfo/pgpool-general
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20160308/b6e0bb0d/attachment.html>


More information about the pgpool-general mailing list