From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: strange buildfarm failures |
Date: | 2007-05-02 13:18:31 |
Message-ID: | 20070502131831.GD4585@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-05-02 13:26:39 | Sequential scans |
Previous Message | Andrew Dunstan | 2007-05-02 12:33:32 | Re: Feature freeze progress report |