On Tue, Jul 1, 2025 at 6:46 PM Japin Li <japi...@hotmail.com> wrote:
>
>
> Hi, all
>
> I've noticed an inconsistency in the LSN format printed by pg_waldump,
> specifically concerning the lsn: and prev fields in the output.
>
> $ pg_waldump /tmp/pgdata02/pg_wal/00000001000000000000000A 2>/dev/null
> |grep 'AB10260'
> rmgr: XLOG len (rec/tot): 114/ 114, tx: 0, lsn:
> 0/0AB10260, prev 0/0AB10228, desc: CHECKPOINT_SHUTDOWN redo 0/AB10260; ...
> ^
> ^
>
> In the output above, the LSN 0/AB10260 and 0/0AB10260 refer to the same
> logical
> LSN, but are presented with a different number of leading zeros in the lower
> 32-bit part.
>
> Upon further investigation, I grepped the source code for the format specifier
> used:
>
> $ grep '%X\/%08X' -rn src/
> src/bin/pg_waldump/pg_waldump.c:558: printf("rmgr: %-11s len
> (rec/tot): %6u/%6u, tx: %10u, lsn: %X/%08X, prev %X/%08X, ",
>
> This inconsistency, while minor, could be confusing when cross-referencing
> LSNs within pg_waldump's own output or when parsing it programmatically.
Yeah, it seems that this is the only place where we output an LSN in a
mixed style of with and without leading zeros. And when writing an LSN
we typically use the format "%X/%X", so I agree with the proposed
change.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
