| 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | jian he | 2026-01-14 06:15:04 | Re: JumbleQuery ma treat different GROUP BY expr as the same |