Re: WAL segment file descriptor leak on read errors can PANIC the server

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: WAL segment file descriptor leak on read errors can PANIC the server
Date: 2026-10-08 16:22:11
Message-ID: CALj2ACWGPzSsA5uBAxJu5Qp3gKJGcMiJdVtChXQ1tJam7Neavw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Wed, Oct 7, 2026 at 11:55 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> As mentioned upthread [1], I think XLogReaderFree() should also check whether
> seg.ws_file >= 0.
>
> Please find attached a small patch doing that.
>
> [1]: https://postgr.es/m/asNr203eue0R4zpZ@bdtpg

Thanks for sending the patch. I don't think we ever receive or set the
ws_file as a non-negative integer other than -1 (neither from the
BasicOpenFilePerm nor from the core's segment_close callbacks), so !=
-1 or >=0 to mean that it is holding the valid fd are correct. Yes, an
external xlogreader can set it to -2 (for example) to mean invalid fd
in their segment_close callback, but I don't think we have anyone
doing that.

I don't have a strong opinion on changing the existing code as it's
not a correctness issue, for consistency reasons across xlogreader.c,
maybe yes. Others may have different thoughts though.

PS: I looked at the slru_io.c which has a mix of both != -1 and >= 0
for file descriptors, maybe leaving it as-is in xlogreader.c is fine.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-10-08 17:00:34 Re: pgstat: allow a stats kind to use its own dedicated dsa/dshash
Previous Message Rui Zhao 2026-10-08 16:13:29 Re: postgres_fdw: Fix costing of remote sorts without remote estimates