Re: Inconsistent LSN format in pg_waldump output

On Thu, Jul 3, 2025 at 7:32 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> 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 :-)

I had concerns regarding scenarios where users or tools
programmatically search for LSNs or perform string comparisons without
proper parsing, as initially raised by Japin Li. For instance, if a
newer version of the server records an LSN as '0/0AB10228' in the
server log, users attempting to search for this LSN won't find matches
in logs generated by older server versions. While such differences
might be acceptable across major version upgrades, I'm uncertain
whether this inconsistency is appropriate between minor versions.

> 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"

+1

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com