Re: Rethinking placement of latch self-pipe initialization

I wrote:
> Sean Chittenden recently reported that 9.2 can crash after logging
> "FATAL: pipe() failed" if the kernel is short of file descriptors:
> http://archives.postgresql.org/pgsql-general/2012-10/msg00202.php
> ...
> What I think would be a better idea is to fix things so that OwnLatch
> cannot fail except as a result of internal logic errors, by splitting
> out the acquisition of the self-pipe into a separate function named say
> InitializeLatchSupport. The question then becomes where to put the
> InitializeLatchSupport calls. My first thought is to put them near the
> signal-setup stanzas for the various processes (ie, the pqsignal calls)
> similarly to what we did recently for initialization of timeout support.

I experimented with that approach, and found out it didn't work at all,
because there are assorted code paths in which InitProcess and
InitAuxiliaryProcess are called well before we enable signals.
I find that a bit disturbing; it means there is a significant amount
of process-startup code that has a latch available but can't actually
wait on the latch. (Well, it could, but it would never awaken because
it would never react to the signal.) At some point in the future we
may have to do some refactoring in this area. On the other hand, moving
signal-enabling earlier carries its own hazards: the signal handlers
might expect yet other infrastructure to be alive already, and any bug
of that ilk would probably be a lot harder to reproduce and diagnose.

Anyway, the simplest working solution proved to be to put the
InitializeLatchSupport calls in InitProcess and InitAuxiliaryProcess,
plus add them in a few background process types that use InitLatch but
don't call either of those functions. Patch attached. Any objections?

regards, tom lane