While chasing the apparent FD leakage reported by Mike Mascari,
I realized that there are probably code paths in which the postmaster
itself will invoke elog(ERROR) or elog(FATAL). This is fairly likely
anyplace that the postmaster uses routines also used by the backend.
Mascari's example shows that it *will* happen, in the current state of
the code, if the postmaster does enough failed password lookups.
That's a bug of course, but there will always be bugs. Trying to ensure
that the postmaster will never call elog() seems like a losing game;
instead we need to ensure that something acceptable will happen.
Right now, what will happen is a postmaster coredump (or worse,
undefined behavior) due to trying to longjmp through an uninitialized
jmp_buf to return to the never-yet-entered backend main loop. That
doesn't rate as acceptable in my book.
elog() should probably check for being in the postmaster and force
a postmaster shutdown if it gets elog(FATAL). Should elog(ERROR)
do the same, or do we want to try to add a return-to-main-loop
capability in the postmaster? I'm inclined to keep it simple and
just do an orderly shutdown in both cases. Any such code paths that
are out there are obviously not heavily exercised, so I doubt that
it's worth adding new code to try to recover from elog(ERROR).
Comments?
regards, tom lane
