Re: Inconsistent LSN format in pg_waldump output

On Thu, 03 Jul 2025 at 10:16, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> 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
>

Thanks everyone for reviewing this patch. Please find v3 attached.

--
Regards,
Japin Li