Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opkC2-0000Ts-4q for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Nov 2022 05:52:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1opkC0-0006ZD-Vf for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Nov 2022 05:52:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opkC0-0006Z4-MB for pgsql-hackers@lists.postgresql.org; Tue, 01 Nov 2022 05:52:08 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opkBy-000348-BW for pgsql-hackers@postgresql.org; Tue, 01 Nov 2022 05:52:07 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2A15q2iH1091331; Tue, 1 Nov 2022 01:52:02 -0400 From: Tom Lane To: Michael Paquier cc: Peter Eisentraut , pgsql-hackers Subject: Re: Check return value of pclose() correctly In-reply-to: References: <8cd9fb02-bc26-65f1-a809-b1cb360eef73@enterprisedb.com> Comments: In-reply-to Michael Paquier message dated "Tue, 01 Nov 2022 14:35:29 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1091329.1667281922.1@sss.pgh.pa.us> Date: Tue, 01 Nov 2022 01:52:02 -0400 Message-ID: <1091330.1667281922@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier 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 confusion. regards, tom lane