aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-10-14 22:59:56 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2012-10-14 22:59:56 -0400
commite81e8f9342b037246b284bad15e42e21b1929301 (patch)
tree59627e42a18148df513a58884684c9f0d5d4a07c /doc/src
parent8b728e5c6e0ce6b6d6f54b92b390f14aa1aca6db (diff)
downloadpostgresql-e81e8f9342b037246b284bad15e42e21b1929301.tar.gz
postgresql-e81e8f9342b037246b284bad15e42e21b1929301.zip
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.
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions