Re: archive_command failures report confusing exit status

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: archive_command failures report confusing exit status
Date: 2007-12-11 20:06:51
Message-ID: 5832.1197403611@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Am Dienstag, 11. Dezember 2007 schrieb Tom Lane:
>> Doesn't this patch break the behavior that is documented in the comment?
>> Specifically, the case where the restore_command dies on a signal and
>> this is reported to us by the controlling shell as exitcode > 128.
>> We want the archiver to die, but this patch makes it not do so.

> AFAICT, the coding

> WIFSIGNALED(rc) || WEXITSTATUS(rc) > 128

> is simply redundant, because a signal happened exactly when WIFSIGNALED(rc) is
> true.

No, you are confusing the cases "called shell was killed by a signal"
and "called command was killed by a signal, which the shell then turned
around and reported to us as exit > 128".

> I have tested this:

A single test case proves little. You need to consider race conditions
and cases where the shell is ignoring the particular signal. I'm fairly
certain that both of these exit statuses can happen in practice, at
least with some shells/platforms.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-12-11 20:16:33 Re: psql \dFp's behavior
Previous Message Andrew Sullivan 2007-12-11 19:25:19 Re: WORM and Read Only Tables (v0.1)