Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
Subject: Re: Incorrect errno used in OpenWalSummaryFile()
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <aYAf8qDHbpBZ3Rml@paquier.xyz>
Date: Mon, 2 Feb 2026 12:07:57 +0800
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>,
 Robert Haas <robertmhaas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <077771A9-06A7-43E3-ADC8-80DE52C3BB4A@gmail.com>
References: <aYAf8qDHbpBZ3Rml@paquier.xyz>
To: Michael Paquier <michael@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/077771A9-06A7-43E3-ADC8-80DE52C3BB4A%40gmail.com>
Precedence: bulk


> On Feb 2, 2026, at 11:54, Michael Paquier <michael@paquier.xyz> wrote:
>=20
> Hi all,
>=20
> While looking at walsummary.c for a different thread, I have bumped
> into this code:
> OpenWalSummaryFile(WalSummaryFile *ws, bool missing_ok)
> [...]
>    file =3D PathNameOpenFile(path, O_RDONLY);
>    if (file < 0 && (errno !=3D EEXIST || !missing_ok))
>        ereport(ERROR,
>                (errcode_for_file_access(),
>                 errmsg("could not open file \"%s\": %m", path)));
>=20
> And it seems to me that this EEXIST should be an ENOENT?  The top of
> the function also documents that we want to handle an error when a
> summary file does not exist.  The comment makes sense to me, not the
> code.
>=20
> It's also worth noting that this function has two callers, both use
> missing_ok =3D false, meaning that the errno check does not really
> matter today.  If someone plays with this code on HEAD or the
> back-branches and decides to introduce a missing_ok=3Dtrue call, it
> could matter, so I'd rather not change this function signature.
>=20
> This issue has been mentioned here as well, I've just bumped into it
> independently a few hours ago:
> =
https://www.postgresql.org/message-id/tencent_1CA40FCC21C1C770712BC089@qq.=
com
>=20
> Regards,
> --
> Michael
> <wal-summary-errno.patch>


I think this is a correct fix.

```
[EEXIST] O_CREAT and O_EXCL are specified and the file exists.=20
[ENOENT] O_CREAT is not set and the named file does not exist.
```

Here, the open flag is only O_RDONLY, so we should only expect ENOENT.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/