Re: START_REPLICATION silently truncates an overlong LSN component

On Fri, Oct 23, 2026 at 12:24 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> Right, it should be rejected. One my primitive fix idea is to directly specify the
> acceptable strings, like [0-9A-Fa-f/]. PSA the patch.

Thanks for updating the patch!

+ if (fscanf(lfp,
+ "START WAL LOCATION: %" CppAsString2(MAXPG_LSNLEN) "[0-9A-Fa-f/]
(file %08X%16s)%c",

For portability, isn't it better to use [0123456789ABCDEFabcdef/] instead of
[0-9A-Fa-f/]? pg_parse_lsn() also lists the hexadecimal digits explicitly.

- if (fscanf(lfp, "INCREMENTAL FROM LSN: %X/%08X\n", &hi, &lo) > 0)
+ if (fscanf(lfp, "INCREMENTAL FROM LSN: %" CppAsString2(MAXPG_LSNLEN)
"[0-9A-Fa-f/]\n",
+ lsn) > 0)

This change seems to allow a backup label containing "INCREMENTAL FROM
LSN: +0/1"
to bypass the check. Previously, %X accepted the leading sign, causing fscanf()
to return a positive value and the backup to be rejected. With this scanset,
fscanf() returns zero instead.

Since we only need to detect an incremental backup here and don't use
the LSN value, how about using "%s\n" instead of "[0-9A-Fa-f/]\n"? This would
preserve the rejection of the above input while also rejecting malformed
values such as "INCREMENTAL FROM LSN: junk".

Regards,

--
Fujii Masao