Re: Check some unchecked fclose() results

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Check some unchecked fclose() results
Date: 2026-04-02 01:16:33
Message-ID: 53d0ef41-e11e-4d2a-9aaa-48e9f0cf02f9@proxel.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-04-02 01:22:44 Re: pg_waldump: support decoding of WAL inside tarfile
Previous Message jie wang 2026-04-02 01:13:57 Re: Add ParameterDescription message to libpq frontend long message types