]> granicus.if.org Git - postgresql/commit
Split up process latch initialization for more-fail-soft behavior.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 15 Oct 2012 03:00:07 +0000 (23:00 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 15 Oct 2012 03:00:07 +0000 (23:00 -0400)
commiteb5e0d8488451bcfcf81e26fd82dd9687c99b941
tree9abc36ccc604059272755f906e0d5a3760a0661c
parentde31ea98a2c993cf1517f83112fc595f96f56b8a
Split up process latch initialization for more-fail-soft behavior.

In the previous coding, new backend processes would attempt to create their
self-pipe during the OwnLatch call in InitProcess.  However, pipe creation
could fail if the kernel is short of resources; and the system does not
recover gracefully from a FATAL error right there, since we have armed the
dead-man switch for this process and not yet set up the on_shmem_exit
callback that would disarm it.  The postmaster then forces an unnecessary
database-wide crash and restart, as reported by Sean Chittenden.

There are various ways we could rearrange the code to fix this, but the
simplest and sanest seems to be to split out creation of the self-pipe into
a new function InitializeLatchSupport, which must be called from a place
where failure is allowed.  For most processes that gets called in
InitProcess or InitAuxiliaryProcess, but processes that don't call either
but still use latches need their own calls.

Back-patch to 9.1, which has only a part of the latch logic that 9.2 and
HEAD have, but nonetheless includes this bug.
src/backend/port/unix_latch.c
src/backend/port/win32_latch.c
src/backend/storage/lmgr/proc.c
src/include/storage/latch.h