On Tue, Oct 4, 2016 at 2:35 PM, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > FWIW, I'm pretty much -1 on messing with the timing of the socket close >> actions. I broke that once within recent memory, so maybe I'm gun-shy, >> but I think that the odds of unpleasant side effects greatly outweigh any >> likely benefit there. > > I couldn't find any relevant mails in pgsql-hackers. I found no problem with > the attached patch. Do you think this is OK?
Few comments on this patch, I am not sure if following condition is a good idea in ServerLoop() 1650 if (pmState == PM_WAIT_DEAD_END || ClosedSockets) There are no sockets to listen on, so select in the else condition is going to sleep for timeout determined based on the sequence expected. Just before we close sockets in pmdie() it sets AbortStartTime, which determines the timeout for the sleep here. So, it doesn't make sense to ignore it. Instead may be we should change the default 60s sleep to 100ms sleep in DetermineSleepTime(). If not, we need to at least update the comments to indicate the other reason for not polling using select(). * If we are in PM_WAIT_DEAD_END state, then we don't want to accept * any new connections, so we don't call select(), and just sleep. */ memcpy((char *) &rmask, (char *) &readmask, sizeof(fd_set)); - if (pmState == PM_WAIT_DEAD_END) + if (pmState == PM_WAIT_DEAD_END || ClosedSockets) While the postmaster is terminating children, a new connection request may arrive. We should probably close listening sockets before terminating children in pmdie(). Otherwise this patch looks good to me. It applies and compiles cleanly. make check-world doesn't show any failures. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers