<div dir="auto">Thanks for the reply.<div dir="auto">I did more tests (stop pgpool on master node) capturing the traffic at server side, but even from this point of view some of the established connections didn't receive a fin packet from the server to close the connection.</div><div dir="auto">Anyway I'm quite satisfied handling this situation (dead established connections at client side) using the keepalive parameters in the connection string to pgpool.</div><div dir="auto">By,</div><div dir="auto">luca</div></div><br><div class="gmail_quote"><div dir="ltr">Il gio 2 ago 2018, 07:18 Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Hi to all,<br>
> this is my frist email to this ml, and I would like to thanks all the<br>
> community working around the pgpool project.<br>
> <br>
> My current configuration is the following:<br>
> 2 servers both with pgpool 3.7.3 and postgresql 9.4.18 with bdr support and<br>
> watchdog enabled.<br>
> <br>
> Both pgpool and postgers are compiled from source code.<br>
> <br>
> Here below the relevant (I hope) configuration settings for pgpool:<br>
> <br>
> port = 5433<br>
> listen_backlog_multiplier = 2<br>
> serialize_accept = off<br>
> <br>
> num_init_children = 500<br>
> max_pool = 1<br>
> child_life_time = 300<br>
> child_max_connections = 0<br>
> connection_life_time = 0<br>
> client_idle_limit = 0<br>
> <br>
> load_balancing=on<br>
> master_slave_mode = on<br>
> master_slave_sub_mode = 'logical'<br>
> <br>
> use_watchdog = on<br>
> <br>
> In my current environment there are 6 clients and each of them establish<br>
> around 55-65 connections each. When all clients are running around 350<br>
> backend connections are established against the pgpool node where the VIP<br>
> is exposed.<br>
> <br>
> When the total amount of connections is around 350 the problem I'm<br>
> experiencing is the following : issuing as root a pgpool -m fast stop<br>
> command on the master pgpool, quite frequently, not all the connections<br>
> previously established by the client to the VIP are closed at the client<br>
> side.<br>
> <br>
> Issuing, as root, a netstat -antpd | grep 5433 on the client that has not<br>
> closed all connections, I can still see some connections in ESTABLISHED<br>
> state; obviously these connections are the ones the client had established<br>
> to the previous pgpool master.<br>
> <br>
> I've even run a tcpdump capture at the client side to check if a fin packet<br>
> was sent by the old pgpool master (the one holding the VIP) for all the<br>
> connections, but I got evidence, at least from those captures, that not all<br>
> connections,at client side, received a fin packet from server.<br>
> <br>
> Currently we handled this issue configuring in the connection string of our<br>
> client the tcp_keepalives parameters (interval=5, count=2, idle=20).<br>
> I was wondering if the lack of fin packet is dued to a bug or it could be<br>
> normal while stopping pgpool in fast mode.<br>
> <br>
> Regards,<br>
> luca<br>
<br>
In my understanding when Pgpool-II server exits by "pgpool -m fast<br>
stop", close(2) is automatically done by the kernel and FIN packet<br>
will be send out if the pgpool process has a socket to frontend. In<br>
another word, Pgpool-II doesn't need to do anything than call exit(3).<br>
<br>
As far as I know, PostgreSQL behaves like this when they exit.<br>
<br>
Best regards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
</blockquote></div>