On Fri, Sep 16, 2016 at 2:23 PM, Andres Freund <and...@anarazel.de> wrote: >> Every read is an event, and that's what PostmasterIsAlive does. > > But in most places we only do a PostmasterIsAlive if WaitLatch returns > WL_POSTMASTER_DEATH. The only walreceiver related place that doesn't is > WalRcvWaitForStartPosition(). If that's indeed the cause of your issues > this quite possibly could be fixed by doing the > if (!PostmasterIsAlive()) > exit(1); > check not unconditionally, but only after the WaitLatch at the end of > the loop, and only if WL_POSTMASTER_DEATH is returned by WaitLatch()? > That'll be a minor behaviour change for the WALRCV_RESTARTING, but that > seems fine, we'll just loop once more outside (after a quick glance at > least).
At least some of the latch implementations already check PostmasterIsAlive() internally to avoid returning spurious events; and secure_read() at least assumes that the WL_POSTMASTER_DEATH return is reliable and doesn't need a double-check. So we can probably just remove the check altogether and instead bail out if it returns WL_POSTMASTER_DEATH. That probably saves a system call per loop iteration even on platforms where the kernel doesn't exhibit any surprising behavior. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
