| 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: | Whole Thread | Raw Message | 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 |