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                      
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to