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
