I wrote:
> Hmm ... I was about to say that the postmaster never sets
> PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW
> could do it? Does the postmaster ever execute PG_TRY?
Doh, I bet that's it, and it's not the postmaster that's at issue
but PG_TRY blocks executed during subprocess startup. Inheritance
of a PG_exception_stack setting from the postmaster could only happen if
the postmaster were to fork() within a PG_TRY block, which I think we
can safely say it doesn't. But suppose we get an elog(ERROR) inside
a PG_TRY block when there is no outermost longjmp catcher. elog.c
will think it should longjmp, and that will eventually lead to
executing
#define PG_RE_THROW() \siglongjmp(*PG_exception_stack, 1)
with PG_exception_stack = NULL; which seems entirely likely to cause
a stack smash of gruesome dimensions. What's more, nothing would have
been printed to the postmaster log beforehand, agreeing with observation.
Personally I think the correct fix is to make PG_RE_THROW deal sanely
with the case of PG_exception_stack = NULL, that is, turn it into an
elog(FATAL) with the original error text. If you try to fix it by
making a setjmp occur earlier, there's still the problem of "what
about PG_TRY earlier than that"?
This might be more code than we want in a macro, though, especially
since this is presumably not a performance-critical path. I'm tempted
to change the macro to just call a pg_re_throw() subroutine. Thoughts?
regards, tom lane