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