Re: WAL segment file descriptor leak on read errors can PANIC the server - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: WAL segment file descriptor leak on read errors can PANIC the server
Date
Msg-id asSWVZA5KP5PAXP0@bdtpg
Whole thread
In response to Re: WAL segment file descriptor leak on read errors can PANIC the server  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On Tue, Oct 06, 2026 at 07:27:24AM +0900, Michael Paquier wrote:
> On Mon, Oct 05, 2026 at 09:20:27AM +0000, Bertrand Drouvot wrote:
> > The comment above segment_close() says that ws_file shall be set to a negative
> > number, while both this callback and XLogReaderFree() check for -1. I wonder if
> > they should test >= 0 instead?
> 
> Probably just checking for negative is fine here, yes.

Yeah.

> > Worth mentioning that this is intended for descriptors not managed by another
> > cleanup mechanism, such as those returned by BasicOpenFile()?  Otherwise, using
> > it with OpenTransientFile() could result in segment_close() being called with a
> > stale descriptor.
> 
> Hmm.  How would you reword this comment?

Something like?

"
/*
 * Register a memory reset callback to close an open WAL segment.
 *
 * This is intended for unmanaged file descriptors, such as those returned by
 * BasicOpenFile().  It should not be used for descriptors subject to another
 * cleanup mechanism, such as those returned by OpenTransientFile(), as those
 * may already be closed when this callback runs.
 */
"

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Session in aborted transaction misses effective_wal_level change
Next
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Parallel Apply