On Wed, Jul 2, 2025 at 10:56 PM Japin Li <japinli@hotmail.com> wrote:
>
> On Tue, 01 Jul 2025 at 22:00, Japin Li <japinli@hotmail.com> wrote:
> > On Tue, 01 Jul 2025 at 13:39, Álvaro Herrera <alvherre@kurilemu.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.
Interesting. While this is a better format, could it break
compatibility with existing tools that for example compares LSN
strings?
> >
> > Agreed. I believe %X/%08X is better.
>
> Patch to standardize LSN formatting with zero-padding.
Thank you for updating the patch. I think this patch doesn't need to
update .po files as we do that at once when doing the translation
update.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
