Tom Lane wrote:
> 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.
I agree that that would be a bug and we should fix it, but I don't think
it explains the problem we're seeing because there is no PG_TRY block
in the autovac startup code that I can see :-(
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
