| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Fix WAL block image length diagnostic |
| Date: | 2026-09-04 08:15:55 |
| Message-ID: | app-OoQAe2TDBorI@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Sep 04, 2026 at 01:31:03PM +0530, Ayush Tiwari wrote:
> While reading DecodeXLogRecord(), I noticed that one error path checks
> blk->bimg_len but prints blk->data_len. The latter is the length of
> resource manager data and can be unrelated to the malformed block image.
> [I'm assuming intention was always to print blk->bimg_len]
Ah, yeah, it looks like you are right on this one. Showing data_len
makes no sense.
> The attached patch reports bimg_len instead. The typo was introduced
> with WAL compression in 57aa5b2bb11 and is present in all supported
> branches, so I think it should be backpatched through 14?
Yes. Will check later..
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ewan Young | 2026-09-04 08:20:51 | Re: Introducing find_all_inheritors_ordered() |
| Previous Message | Grigorev Jurij | 2026-09-04 08:01:05 | Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ |