[pgpool-general: 6173] PGPOOL 3.7.3 on -m fast stop does not send the fin wait packet to all connections

[luca ceccarani]

Hi to all,
this is my frist email to this ml, and I would like to thanks all the
community working around the pgpool project.

My current configuration is the following:
2 servers both with pgpool 3.7.3 and postgresql 9.4.18 with bdr support and
watchdog enabled.

Both pgpool and postgers are compiled from source code.

Here below the relevant (I hope) configuration settings for pgpool:

port = 5433
listen_backlog_multiplier = 2
serialize_accept = off

num_init_children = 500
max_pool = 1
child_life_time = 300
child_max_connections = 0
connection_life_time = 0
client_idle_limit = 0

load_balancing=on
master_slave_mode = on
master_slave_sub_mode = 'logical'

use_watchdog = on

In my current environment there are 6 clients and each of them establish
around 55-65 connections each. When all clients are running around 350
backend connections are established against the pgpool node where the VIP
is exposed.

When the total amount of connections is around 350 the problem I'm
experiencing is the following : issuing as root a pgpool -m fast stop
command on the master pgpool, quite frequently, not all the connections
previously established by the client to the VIP are closed at the client
side.

Issuing, as root, a netstat -antpd | grep 5433 on the client that has not
closed all connections, I can still see some connections in ESTABLISHED
state; obviously these connections are the ones the client had established
to the previous pgpool master.

I've even run a tcpdump capture at the client side to check if a fin packet
was sent by the old pgpool master (the one holding the VIP) for all the
connections, but I got evidence, at least from those captures, that not all
connections,at client side, received a fin packet from server.

Currently we handled this issue configuring in the connection string of our
client the tcp_keepalives parameters (interval=5, count=2, idle=20).
I was wondering if the lack of fin packet is dued to a bug or it could be
normal while stopping pgpool in fast mode.

Regards,
luca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20180730/f0d3e2c4/attachment.html>