[pgpool-general: 7151] Re: Long wait time when stopping Pgpool

Araujo Manuel Emilio emilio.araujo at gmail.com
Fri Jul 17 02:05:21 JST 2020


I always use pgpool -m fast stop.
According to the official documentation:

Stopping Pgpool-II main server

Here are options for the stop mode.

-m shutdown_mode
Stop Pgpool-II. shutdown_mode is either smart, fast or immediate. If smart is specified, Pgpool-II will wait for all clients are disconnected. If fast or immediate are specified, Pgpool-IIimmediately stops itself without waiting for all clients are disconnected. There's no difference between fast and immediatein the current implementation.

NOTE: Remember stop pgpools before postgres services. pgpool standby first and continue with the master. The same for postgres instances.

On 16 Jul 2020, at 17:41, Nikhil Shetty <nikhil.dba04 at gmail.com> wrote:

> Hi Team,
> I am testing pgpool for my workload.We have three nodes of pgpool used as a load balancer and connection pooler across three nodes of database servers.
> All application connections to the database are through the pgpool. Without stopping the application, if we want to stop the pgpool using "systemctl stop edb-pgpool-4.0" then it takes a long time because connections are still coming to the pgpool. Pgpool is stopped only after no new connections appear + existing connections are terminated.
> Even after Pgpool is stopped, I can see that files(.s.PGSQL.9898 and .s.PGSQL.9999) under socket_dir which in our case is /tmp are not removed. This does not allow the pgpool to start using  "systemctl start edb-pgpool-4.0". We have to manually remove the files under /tmp and then start pgpool.
> I have two questions:
> 1. Before stopping pgpool, how can we prevent new connections from coming into pgpool without stopping the application and terminate the existing connections so that the stop command does not wait.
> 2. After stopping pgpool, why are files under /tmp not removed?
> PS:Files are removed from /tmp if there are no connections via pgpool(this will never be the case in production environment)
> _______________________________________________
> 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/20200716/1fc4104a/attachment.html>

More information about the pgpool-general mailing list