Message-ID: <53d0ef41-e11e-4d2a-9aaa-48e9f0cf02f9@proxel.se>
Date: Thu, 2 Apr 2026 03:16:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Check some unchecked fclose() results
To: Chao Li <li.evan.chao@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <191398CF-C65F-4751-B704-7C904BCBB80B@gmail.com>
 <BFE80E46-3730-4178-B305-0AA1E6A831A9@gmail.com>
From: Andreas Karlsson <andreas@proxel.se>
Content-Language: en-US
In-Reply-To: <BFE80E46-3730-4178-B305-0AA1E6A831A9@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/53d0ef41-e11e-4d2a-9aaa-48e9f0cf02f9%40proxel.se>
Precedence: bulk

On 3/23/26 3:22 AM, Chao Li wrote:
>> My criteria for including cases in this patch were basically:
>>
>> * only output file descriptors
>> * code paths where the logic is relatively clear and easy to handle

Those criteria are not enough as can be evidenced from some of the cases 
which you patched. I do not see why you would want to error out in the 
following two cases:

1. When writing to e.g. a log file and we do not call pg_fatal() if a 
write fails. Then it makes no sense to die on failed fclose().

2. When creating an empty file. I could be wrong here but in that case 
fclose() cannot fail. Arguably maybe we should use open() and close() 
then instead of fopen() and fclose() but handling an error which can 
never happen does not add any value.

Please review your patches a bit careful before submitting. You are 
doing some good work with finding bugs and reviewing patches but it is 
clear you do not spend enough time per mail making sure it is not a 
false positive.

-- 
Andreas Karlsson
Percona