On Mon, May 17, 2010 at 10:40 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Mon, May 17, 2010 at 10:20 PM, Robert Haas <robertmh...@gmail.com> wrote: >> OK, I think I understand now. But, the SIGTERM sent by the postmaster >> doesn't kill the recovery process unconditionally. It will invoke >> StartupProcShutdownHandler(), which will set set shutdown_requested = >> true. That gets checked by RestoreArchivedFile() and >> HandleStartupProcInterrupts(), and I think that neither of those can >> get invoked until after the control file has been updated. Do you see >> a way it can happen? > > Yeah, the way is: > StartupXLOG() --> ReadCheckpointRecord() --> ReadRecord() --> > XLogPageRead() --> XLogFileReadAnyTLI() --> XLogFileRead() --> > RestoreArchivedFile() > > ReadCheckpointRecord() is called before pg_control is updated.
OK. In that case, I'm wondering if we should reverse course and rejigger the logic so that the shutdown gets processed when we transition to PM_RECOVERY. Seems like that might be simpler. > ISTM that walreceiver might be invoked even after shutdown is requested. > We should prevent the postmaster from starting up walreceiver if > Shutdown > NoShutdown? Well, when we did the previous shutdown patch, we decided it was not right to kill walreceiver until all backends had exited, so it seems inconsistent to make the opposite decision here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
