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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to