Install a "dead man switch" to allow the postmaster to detect cases where
commit82d1cc5b8fa8f178a7151d3ca3474452a65f5f11
authortgl <tgl>
Tue, 5 May 2009 19:59:00 +0000 (5 19:59 +0000)
committertgl <tgl>
Tue, 5 May 2009 19:59:00 +0000 (5 19:59 +0000)
treec20bd0ed5784fb583cb504cddedba13bbc86b99e
parent1198ec5ad9d9222ee42bba50dc32c4b204604fe4
Install a "dead man switch" to allow the postmaster to detect cases where
a backend has done exit(0) or exit(1) without having disengaged itself
from shared memory.  We are at risk for this whenever third-party code is
loaded into a backend, since such code might not know it's supposed to go
through proc_exit() instead.  Also, it is reported that under Windows
there are ways to externally kill a process that cause the status code
returned to the postmaster to be indistinguishable from a voluntary exit
(thank you, Microsoft).  If this does happen then the system is probably
hosed --- for instance, the dead session might still be holding locks.
So the best recovery method is to treat this like a backend crash.

The dead man switch is armed for a particular child process when it
acquires a regular PGPROC, and disarmed when the PGPROC is released;
these should be the first and last touches of shared memory resources
in a backend, or close enough anyway.  This choice means there is no
coverage for auxiliary processes, but I doubt we need that, since they
shouldn't be executing any user-provided code anyway.

This patch also improves the management of the EXEC_BACKEND
ShmemBackendArray array a bit, by reducing search costs.

Although this problem is of long standing, the lack of field complaints
seems to mean it's not critical enough to risk back-patching; at least
not till we get some more testing of this mechanism.
src/backend/postmaster/postmaster.c
src/backend/storage/ipc/ipci.c
src/backend/storage/ipc/pmsignal.c
src/backend/storage/lmgr/proc.c
src/backend/utils/init/globals.c
src/include/miscadmin.h
src/include/postmaster/postmaster.h
src/include/storage/pmsignal.h