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

[Tatsuo Ishii]

Assuming you mean pgdg yum repositories by
http://www.postgresql.org/download/linux/redhat/, yhe maintainer of it
is Devrim and he is on this list.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

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