Re: Inconsistent LSN format in pg_waldump output

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Japin Li <japinli(at)hotmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Inconsistent LSN format in pg_waldump output
Date: 2025-07-07 12:18:20
Message-ID: 202507071218.wdjncwmo7jxl@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Jul-05, Masahiko Sawada wrote:

> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> >
> > On 2025-Jul-04, Japin Li wrote:
> >
> > > I've opted to directly use %X/%08X for LSN formatting in this patch, with an
> > > accompanying comment near LSN_FORMAT_ARGS.
> >
> > Thank you! I support this approach and intend to work on getting this
> > patch committed soon after some more review, unless there are further
> > objections.
>
> +1. I think we need to update LSN values in the documentation too.

You're right, we had a few of those. I grepped for them and adjusted
what I found. I could have missed some, because there's a bunch of
other values that also look like slash-separated hexadecimal numbers.
The only case where I did something other than adding a leading zero was
the example output for gist_page_opaque_info() because I wasn't sure
that the 'nsn' column was also going to be printed as an LSN :-) so I
just ran the example query using one index from the regression database.

And pushed. Thanks!

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"No tengo por qué estar de acuerdo con lo que pienso"
(Carlos Caszeli)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-07-07 12:21:14 Re: amcheck support for BRIN indexes
Previous Message Tomas Vondra 2025-07-07 12:10:07 Re: amcheck support for BRIN indexes