From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Inconsistent LSN format in pg_waldump output |
Date: | 2025-07-01 11:39:05 |
Message-ID: | 202507011139.hubx6fea6sbz@alvherre.pgsql |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Daniil Davydov | 2025-07-01 11:56:11 | Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION |
Previous Message | Evgeny Voropaev | 2025-07-01 11:08:12 | Re: Add 64-bit XIDs into PostgreSQL 15 |