On 11/14/16 4:38 AM, Ashutosh Bapat wrote: > The patch 02_close_listen... closes the listen sockets > explicitly when it's known that postmaster is going to stop all the > children and then die. I have tried to see, if there's a possibility > that it closes the listen sockets but do not actually die, thus > causing a server which doesn't accept any connections and doesn't die. > But I have not found that possibility.
I can see the point of this, but I'm not sure whether this is always a good idea. Some people "monitor" postgres shutdown with PQping() or by parsing the error messages that the client gets. If we just close the sockets as soon as possible, we lose all communication and can't tell what's going on anymore. If your HA system insists that the crashing server be completely shut down before moving on, then maybe that can be refined somehow instead? I haven't seen any analysis in this thread of how much of a problem this really is. For example, could we keep the socket open longer but reject connection attempts faster in this state? This patch only changes the behavior in the case of a crash or an immediate shutdown, but not for the other shutdown modes. I don't think it is good to create different behaviors for different modes. A long time ago, ClosePostmasterPorts() essentially had the job to close all postmaster sockets. Every single call thereof is in fact commented with /* Close the postmaster's sockets */. (Ancient postgres code uses "port" as a more general term for socket or communication port.) Now it has accumulated other tasks so it is more of a ClosePostmasterOnlyResourcesInChild(). So if we were to introduce a ClosePostmasterSockets() somehow, we should adjust the naming and the comments so that we don't have two similar-sounding functions with confusing comments. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
