Re: pg_walinspect: fix LSN validation messages and empty range handling - Mailing list pgsql-hackers

From Chao Li
Subject Re: pg_walinspect: fix LSN validation messages and empty range handling
Date
Msg-id 4179E230-F999-437E-B964-94659F0AD3D7@gmail.com
Whole thread
In response to Re: pg_walinspect: fix LSN validation messages and empty range handling  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: pg_walinspect: fix LSN validation messages and empty range handling
List pgsql-hackers

> On Sep 21, 2026, at 16:55, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> On Sun, Sep 20, 2026 at 11:56 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>> PFA v2:
>
> Thanks for reporting and sending the patch.
>
> Yes, it's an oversight in 5c1b6628075a. +1 for "must be less than or
> equal to", since that is the wording used elsewhere in the code.
>
> That said, an error is raised only when no valid record is found at or
> after the start LSN (or the input LSN), either because that WAL is
> already removed or because nothing valid follows it, which is what the
> documentation already mentions. Once a record is found,
> pg_get_wal_record_info() emits it, whereas the range functions emit
> only the records ending at or before the end LSN, so equal start and
> end LSNs emit nothing. A start LSN equal to the current LSN ends up
> the same way, since the end LSN is capped at the current LSN, making
> the two equal, and it errors because nothing follows the current LSN.
>
> The v2 patch looks good to me. I adjusted the commit message and
> re-attached the patch, which I think is ready for commit. I'm fine not
> back-patching this for a couple of reasons. The error is still
> reported in the back-branches, just with slightly incorrect wording
> matching the condition the code uses, and it went unnoticed for many
> years. CC-ing Michael for any thoughts.

Thanks for reviewing and updating v2.

>
> While here, do we also need to fix AlterSubscription()'s skip WAL
> location and ParseVariableDouble()'s min and max bound messages? Maybe
> separately.
>

Yeah, we can do that. As those two functions are in core, and 0001 changes the extension, I put the new changes to
0002.

PFA v3.

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





Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] Explain what the default output_plugin_libraries do
Next
From: Michael Paquier
Date:
Subject: Re: Support for 8-byte TOAST values, round two