From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
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 03:42:52 |
Message-ID: | 4895.1178077372@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I'm wondering if it wouldn't be more robust to define a longjmp target
> block before calling BaseInit(), and have it exit cleanly in case of
> failure (which is what you say elog.c should be doing if there is no
> target block).
No, because elog is already supposed to deal with that case; and does,
every time you connect to a bad database name for example. If it's
failing, the question to answer is why.
> In errstart(), it is checked if PG_exception_stack is NULL. Now, this
> symbol is defined in elog.c and initialized to NULL, but I wonder if a
> child process inherits the value that postmaster set, or it comes back
> to NULL.
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? (And if so,
should it? The postmaster really ought not be dealing in anything
very hairy --- it should be passing such work off to children.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-02 03:50:46 | Re: Patch queue triage |
Previous Message | Greg Smith | 2007-05-02 03:42:47 | Re: Patch queue triage |