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


Reply via email to