Re: [RFC] Should we fix postmaster to avoid slow shutdown? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Date
Msg-id 1416.1479760254@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] Should we fix postmaster to avoid slow shutdown?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [RFC] Should we fix postmaster to avoid slow shutdown?  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 1. Should we try to avoid having the stats collector write a stats
> file during an immediate shutdown?  The file will be removed anyway
> during crash recovery, so writing it is pointless.

The point I was trying to make is that I think the forced-removal behavior
is not desirable, and therefore committing a patch that makes it be graven
in stone is not desirable either.

The larger picture here is that Takayuki-san wants us to commit a patch
based on a customer's objection to 9.2's behavior, without any real
evidence that the 9.4 change isn't a sufficient solution.  I've got
absolutely zero sympathy for that "the stats collector might be stuck in
an unkillable state" argument --- where's the evidence that the stats
collector is any more prone to that than any other postmaster child?
And for that matter, if we are stuck because of a nonresponding NFS
server, how is a quicker postmaster exit going to help anything?
You're not going to be able to start a new postmaster if the data
directory is on a nonresponsive server.

I'd be willing to entertain a proposal to make the 5-second limit
adjustable, but I don't think we need entirely new behavior here.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Postgres abort found in 9.3.11
Next
From: Joe Conway
Date:
Subject: Re: dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.