Re: strange buildfarm failures

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.

In response to

Responses

Browse pgsql-hackers by date

  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