| From: | surya poondla <suryapoondla4(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Rahul <rahul(at)rhyadav(dot)dev>, Pgsql Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Ju Grigorev <ju(dot)grigorev(at)ftdata(dot)ru> |
| Subject: | Re: Wrong LSN in WAL decoding error messages |
| Date: | 2026-11-02 04:49:13 |
| Message-ID: | CAOVWO5qet=69kcoju=si6iyuYi5AAtxBH4KAu+3d58TmtOwgxg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Fujii,
EndRecPtr is the starting position for the next read, which does not
> always correspond to the start of the failing record. No? For example,
> if decoding fails on the first record after a page header, EndRecPtr
> still points to the start of the page?
>
Yes, you're right. When the next record starts right after a page header,
EndRecPtr points to the start of the page, so the prefix would be off
by the header size there. The LSN at the end of the message, from
0001, is still exact, since XLogDecodeNextRecord() skips any page header
before passing RecPtr to
DecodeXLogRecord().
> OTOH, if the goal is consistency with pg_rewind and pg_walinspect,
> I'm fine with using EndRecPtr. But, as with 0001, I don't think the test
> change in 0002 is necessary.
0002 is mainly a consistency change with pg_rewind and pg_walinspect.
Regards,
Surya Poondla
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hayato Kuroda (Fujitsu) | 2026-11-02 05:33:35 | RE: Incorrect CONTEXT reported for errors from parallel apply worker in logical replication |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-11-02 04:47:36 | RE: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation |