On Wed, Jun 28, 2017 at 8:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.de> writes: >> On 2017-06-27 14:59:18 -0400, Tom Lane wrote: >>> However, it's certainly arguable that this is too much change for an >>> optional post-beta patch. > >> Yea, I think there's a valid case to be made for that. I'm still >> inclined to go along with this, it seems we're otherwise just adding >> complexity we're going to remove in a bit again. > > I'm not hearing anyone speaking against doing this now, so I'm going > to go ahead with it.
+1 for going for it. Besides pg_ctl it would also help cluster management software. In Patroni we basically reimplement pg_ctl to get at the started postmaster pid to detect a crash during postmaster startup earlier and to be able to reliably cancel start. Getting the current state from the pid file sounds better than having a loop poke the server with pg_isready. To introduce feature creep, I would like to see more detailed states than proposed here. Specifically I'm interested in knowing when PM_WAIT_BACKENDS ends. When we lose quorum we restart PostgreSQL as a standby. We use a regular fast shutdown, but that can take a long time due to the shutdown checkpoint. The leader lease may run out during this time so we would have to escalate to immediate shutdown or have a watchdog fence the node. If we knew that no user backends are left we can let the shutdown checkpoint complete at leisure without risk for split brain. Regards, Ants Aasma -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
