Re: pg_upgrade and system() return value - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade and system() return value
Date
Msg-id 21292.1358698487@sss.pgh.pa.us
Whole thread Raw
In response to pg_upgrade and system() return value  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade and system() return value
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Can someone comment on the attached patch?  pg_upgrade was testing if
> system() returned a non-zero value, while I am thinking I should be
> adjusting system()'s return value with WEXITSTATUS().  

AFAIK it's not very good style to test the result as an integer, and
testing for -1 is not an improvement on that.  Actually it's a
disimprovement, because the only case where the standard guarantees
anything about the integer representation is that zero corresponds
to "exited with status 0".  See the Single Unix Spec, wherein system's
result code is defined in terms of wait's, and the wait man page saith
If and only if the status returned is from a terminated child processthat returned 0 from main() or passed 0 as the
statusargument to_exit() or exit(), the value stored at the location pointed to bystat_loc will be 0. Regardless of its
value,this information may beinterpreted using the following macros ...
 

If you want to do something different, then you could test for
WIFEXITED && WEXITSTATUS == 0.  (Testing the latter alone is flat
wrong.)  But I'm not particularly convinced that that's an improvement
on what's there now.  I note that your proposed patch would prevent
any possibility of printing debug information about failure cases,
since it loses the original result value.

In short: it's not broken now, but this patch would break it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [BUGS] BUG #7809: Running pg_dump on slave w/ streaming replication fails if there are unlogged tables
Next
From: Tom Lane
Date:
Subject: Re: ALTER command reworks