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. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
