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