Re: Check return value of pclose() correctly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Check return value of pclose() correctly
Date: 2022-11-01 05:52:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Oct 31, 2022 at 09:12:53AM +0100, Peter Eisentraut wrote:
>> (A failure to run the command issued by popen() is usually reported via the
>> pclose() status, so while you can often get away with not checking fclose()
>> or close(), checking pclose() is more often useful.)

> - if (WIFEXITED(exitstatus))
> + if (exitstatus == -1)
> + {
> + snprintf(str, sizeof(str), "%m");
> + }
> This addition in wait_result_to_str() looks inconsistent with the
> existing callers of pclose() and ClosePipeStream() that check for -1
> as exit status. copyfrom.c and basebackup_to_shell.c fall into this
> category. Wouldn't it be better to unify everything?

I think there are two issues here. POSIX says

Upon successful return, pclose() shall return the termination status
of the command language interpreter. Otherwise, pclose() shall return
-1 and set errno to indicate the error.

That is, first you need to make sure that pclose returned a valid
child process status, and then you need to decode that status.
It's not obvious to me that -1 is disjoint from the set of possible
child statuses. Do we need to add some logic that clears and then
checks errno?

Also, we have a number of places --- at least FreeDesc() and
ClosePipeStream() --- that consider pclose()'s return value to be
perfectly equivalent to that of close() etc, because they'll
return either one without telling the caller which is which.
It seems like we have to fix that if we want to issue sane
error reports.

This patch isn't moving things forward on this fundamental

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-11-01 05:55:33 Re: [patch] Have psql's \d+ indicate foreign partitions
Previous Message Michael Paquier 2022-11-01 05:43:07 Re: Lock on ShmemVariableCache fields?