Re: Inconsistent LSN format in pg_waldump output

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/

In response to

Responses

Browse pgsql-hackers by date

  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