Re: BUG #19598: pg_waldump: -s/-e accept out-of-range WAL locations and silently use the low 32 bits

On Tue, Aug 4, 2026 at 5:54 PM Zexin Li <lizi(dot)openmind(at)gmail(dot)com> wrote:
> The same pattern parses user-supplied LSNs in pg_recvlogical (-I/-E)
> and pg_receivewal (-E); pg_basebackup and pg_rewind only parse
> server-returned strings. I kept this patch to pg_waldump to match
> the report's scope, and can send a follow-up moving the helper next
> to option_parse_int() in fe_utils to cover the other two if that
> seems worthwhile.

I think it would be better to improve pg_recvlogical and pg_receivewal as well,
not just pg_waldump, by introducing a common LSN parsing helper in,
for example, src/common. That would let frontend tools share exactly
the same LSN syntax checks.

pg_basebackup, pg_verifybackup, pg_rewind, and pg_combinebackup also parse LSN
but are a bit different, since they mostly parse LSNs from server responses,
backup manifests, backup_label files, or timeline history files rather than
direct command-line input. So they're less likely to see arbitrary invalid LSNs
from users.

Still, if we introduce a common LSN parser, it seems worth considering
converting those existing sscanf("%X/%08X") call sites as well. That would
make malformed metadata fail earlier and avoid having several slightly
different LSN parsers in frontend code. This should be done as a separate
patch from the pg_waldump/pg_recvlogical/pg_receivewal improvement,
though.

BTW, at least for me this looks more like an improvement than a bug fix.
So I think it should target v20devel.

Regards,

--
Fujii Masao