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

[Tatsuo Ishii]

> 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

In my understanding when Pgpool-II server exits by "pgpool -m fast
stop", close(2) is automatically done by the kernel and FIN packet
will be send out if the pgpool process has a socket to frontend. In
another word, Pgpool-II doesn't need to do anything than call exit(3).

As far as I know, PostgreSQL behaves like this when they exit.

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