Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69
Date
Msg-id 95257337-421E-474B-9799-3B807974DDD6@gmx.net
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Upgrade to Autoconf 2.69
List pgsql-hackers
That was probably me. I'll look into it.



> On Jan 6, 2014, at 11:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Bruce Momjian <bruce@momjian.us> writes:
>>> On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
>>> 3. pg_upgrade ignores the fact that pg_resetxlog failed, and keeps going.
> 
>> Does pg_resetxlog return a non-zero exit status?  If so, pg_upgrade
>> should have caught that and exited.
> 
> It certainly does:
> 
>    if (errno)
>    {
>        fprintf(stderr, _("%s: could not read from directory \"%s\": %s\n"),
>                progname, XLOGDIR, strerror(errno));
>        exit(1);
>    }
> 
> The bug is that pg_upgrade appears to assume (in many places not just this
> one) that exec_prog() will abort if the called program fails, but *it
> doesn't*, contrary to the claim in its own header comment.  This is
> because pg_log(FATAL, ...) doesn't call exit().  pg_fatal() does, but
> that's not what's being called in the throw_error case.
> 
> I imagine that this used to work correctly and got broken by some
> ill-advised refactoring, but whatever the origin, it's 100% broken today.
> 
>            regards, tom lane
> 



pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: ERROR: missing chunk number 0 for toast value
Next
From: "MauMau"
Date:
Subject: Re: [bug fix] multibyte messages are displayed incorrectly on the client