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

[Muhammad Usama]

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/20160307/5acabdc1/attachment.html>