| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Kiran Kaki <itskkpg(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Re: pg_walinspect: fix LSN validation messages and empty range handling |
| Date: | 2026-09-21 08:55:05 |
| Message-ID: | CALj2ACWgKeFhuxOxu4fs0msb2JSM6-OWK_hQMqfzD90-Jrt-dw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-input-LSN-validation-error-messages-in-pg_wal.patch | application/octet-stream | 6.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2026-09-21 09:09:58 | Re: Logical replication can lose an update after concurrent index invalidation |
| Previous Message | vignesh C | 2026-09-21 08:47:52 | Re: Logical replication can lose an update after concurrent index invalidation |