| 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
>
| 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 |