Re: pg_walinspect: fix LSN validation messages and empty range handling

From: Kiran Kaki <itskkpg(at)gmail(dot)com>
To: bharath(dot)rupireddyforpostgres(at)gmail(dot)com
Cc: li(dot)evan(dot)chao(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, michael(at)paquier(dot)xyz
Subject: Re: pg_walinspect: fix LSN validation messages and empty range handling
Date: 2026-09-21 15:28:09
Message-ID: CAD0dvCRew7csucknehmM+n+R=9fSCbDAAbyiq5xTc3UNgxT8Gg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

👍

Kiran reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

On Mon, Sep 21, 2026, 1:55 AM Bharath Rupireddy <
bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:

> Hi,
>
> On Sun, Sep 20, 2026 at 11:56 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)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.
>
> While here, do we also need to fix AlterSubscription()'s skip WAL
> location and ParseVariableDouble()'s min and max bound messages? Maybe
> separately.
>
> [1]
> DROP TBALE t1;
> CREATE TABLE t1 (a int);
> SELECT pg_current_wal_lsn() AS lsn \gset
> INSERT INTO t1 VALUES (1);
>
> -- start = end, the record there ends past end, no rows
> SELECT * FROM pg_get_wal_records_info(:'lsn', :'lsn');
>
> -- input at a valid record, one row
> SELECT * FROM pg_get_wal_record_info(:'lsn');
>
> -- start = end = current, nothing follows, error
> SELECT * FROM pg_get_wal_records_info(pg_current_wal_lsn(),
> pg_current_wal_lsn());
>
> -- input = current, nothing follows, error
> SELECT * FROM pg_get_wal_record_info(pg_current_wal_lsn());
>
> -- start = current, end capped to current, so start = end again, error
> SELECT * FROM pg_get_wal_records_info(pg_current_wal_lsn(),
> 'FFFFFFFF/FFFFFFFF');
>
> -- recycle the segment holding :lsn
> SELECT pg_switch_wal();
> CHECKPOINT;
>
> -- start = end, WAL already removed, error
> SELECT * FROM pg_get_wal_records_info(:'lsn', :'lsn');
>
> --
> Bharath Rupireddy
> Amazon Web Services: https://aws.amazon.com
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kiran Kaki 2026-09-21 15:29:34 Re: pg_walinspect: fix LSN validation messages and empty range handling
Previous Message Osama Abdul Qader 2026-09-21 15:25:47 Re: Severe performance degradation with concurrent updates due to excessive EvalPlanQual (EPQ) re‑evaluation