Re: Inconsistent LSN format in pg_waldump output

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

On Wed, Jul 02, 2025 at 08:57:45PM +0200, Alvaro Herrera wrote:
> I think a tool would have to be severely miswritten in order to become
> broken from this change. Our own code to scan LSNs is to use
> scanf('%X/%X') which should work just fine with and without the leading
> zeroes. I honestly don't see anybody coding this in any different way
> that could not cope with the leading zeroes :-)

Yep. If you do not want this new policy to be forgotten by new paths,
I'd suggested to standarize that with something like that, close to
the existing LSN_FORMAT_ARGS():
#define LSN_FORMAT "%X/%08X"

I was pretty sure that this point was mentioned when LSN_FORMAT_ARGS
got discussed, but my impression is wrong as Alvaro already said
upthread. I'd suggest to take this extra step now instead of
hardcoding %08X everywhere. We may perhaps go down to backpatch
LSN_FORMAT_ARGS() and this LSN_FORMAT in the back-branches, leading to
less friction when backpatching fixes, but we don't deal with many
stable fixes that would require these.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-07-02 22:57:42 Re: libpq OpenSSL and multithreading
Previous Message Jelte Fennema-Nio 2025-07-02 22:18:07 Re: BackendKeyData is mandatory?