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

From Bharath Rupireddy
Subject Re: WAL segment file descriptor leak on read errors can PANIC the server
Date
Msg-id CALj2ACVFgGRcEmMJ9rJqrBPx+YMgatSz=aPCfKhQh6+sMUZ5Bg@mail.gmail.com
Whole thread
In response to Re: WAL segment file descriptor leak on read errors can PANIC the server  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: WAL segment file descriptor leak on read errors can PANIC the server
List pgsql-hackers
Hi,

On Fri, Sep 25, 2026 at 4:25 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> > segment. I would imagine here that the sane move is to register a
> > callback *iff* we open a segment.  So, add a boolean flag in the state
> > tracking if the reset callback is registered, and use
> > GetMemoryChunkContext(state) to save the callback in the memory
> > context of the xlogreader state, not the CurrentMemoryContext where
> > the segment is opened.
>
> Agreed. A reader whose page_read callback reads everything from WAL
> buffers, for example with WALReadFromBuffers(), may not call
> segment_open at all, so it has no file to close, and registering a
> callback for it at allocation time is wasted. Registering it lazily on
> the first segment_open call avoids that. I will do it that way in the
> next version, with the callback on the reader's own context.
>
> > Note that xlogreader.h declares a new variable that makes no sense in
> > FRONTEND code.  This needs an #ifdef.
>
> Ah, missed that. I will fix it.
>
> I will address the comments and post new patches soon.

Please find attached the v2 patches implementing lazy registration of
the reset callback, only when a WAL segment is opened. v2-0001 is for
HEAD and PG19. The nocfbot versions are for the back branches.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Report index currently being vacuumed in pg_stat_progress_vacuum
Next
From: vignesh C
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication