Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, David Christensen <david(dot)christensen(at)crunchydata(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL
Date: 2026-01-14 06:17:20
Message-ID: aWc08L0FJLWeXX5v@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 13, 2026 at 01:20:23PM +0500, Andrey Borodin wrote:
> But this particular test of pg_waldump fails due to LSN comparison logic.
> The test expects LSN in saved file to be strictly less than LSN in file name.
> This is violated when wal_consistency_checking is enabled: LSNs are equal.
>
> Maybe we can relax the test here?

Due to the fact that with wal_consistency_checking the block is
copied in the WAL record on a consistent basis. Fun.

There is actually an argument for a backpatch, on top of being able to
enable wal_consistency_checking across the board in stable branches
(which has value on its own). The only reason why the test is not
hitting this failure today is that we would need a needs_backup to be
set when inserting a record to see a block with a LSN value matching,
which could in theory happen if the test is really slow with
concurrent activity that touches a page LSN, or if we add much more
queries to it at some point. Unlikely so, still, you have a point. I
will address that shortly, thanks for the report!
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message jian he 2026-01-14 06:15:04 Re: JumbleQuery ma treat different GROUP BY expr as the same