Re: Inconsistent LSN format in pg_waldump output

On Tue, 01 Jul 2025 at 22:00, Japin Li <japinli(at)hotmail(dot)com> wrote:
> On Tue, 01 Jul 2025 at 13:39, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>> 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.
>>
>
> I initially considered using the %X/%08X format, but observing %X/%X
> consistently elsewhere led me to abandon that idea.
>
>> 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.
>
> Agreed. I believe %X/%08X is better.

Patch to standardize LSN formatting with zero-padding.

--
Regards,
Japin Li