On 2025-Jul-01, Japin Li wrote:
> This inconsistency, while minor, could be confusing when cross-referencing
> LSNs within pg_waldump's own output or when parsing it programmatically.
I agree that we should fix this, but I'd rather add the missing zeros
than remove these ones (the only ones we have):
> XLogRecGetLen(record, &rec_len, &fpi_len);
>
> - printf("rmgr: %-11s len (rec/tot): %6u/%6u, tx: %10u, lsn: %X/%08X, prev %X/%08X, ",
> + printf("rmgr: %-11s len (rec/tot): %6u/%6u, tx: %10u, lsn: %X/%X, prev %X/%X, ",
> desc->rm_name,
> rec_len, XLogRecGetTotalLen(record),
> XLogRecGetXid(record),
I think pg_waldump did things right in this regard, and all other places
were cargo-culting the older broken practice.
IOW I think we should change all occurrences of %X/%X to %X/%08X
instead. There's a ton of them though. See also
https://www.postgresql.org/message-id/flat/CAExHW5ub5NaTELZ3hJUCE6amuvqAtsSxc7O%2BuK7y4t9Rrk23cw%40mail.gmail.com
where LSN_FORMAT_ARGS was invented, but where the width of the second %X
was not discussed.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
