Re: Wrong LSN in WAL decoding error messages

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-10-30 15:52:19
Message-ID: CAOVWO5oH730h3xDB_Ht0mYx73vS3fSZc-4zwHaFYfu_vhn6wSw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Fujii,

> But, do we really need a new test for such a small fix?
>

That's fair. I was the one who asked for the test, but I agree it's a
lot of test code to check an LSN in an error message. I'm happy for 0001 to
go in without it.

Also, what do you think about 0002? It makes pg_waldump's "error in WAL
record at" prefix show where reading failed, instead of the last
good record. pg_rewind's extractPageMap() and pg_walinspect already
work this way. We could make this master only, since it changes output
people may be used to.

Regards,
Surya Poondla

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-10-30 15:59:59 Re: Return pg_control from pg_backup_stop().
Previous Message Greg Burd 2026-10-30 15:28:19 Re: nbtree: opt-in leaf key prefix compression