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

On Fri, Aug 14, 2026, Fujii Masao wrote:
> I wonder if we really need pg_parse_lsn_prefix() for this. Instead,
> how about isolating the LSN token by temporarily NUL-terminating it,
> then passing it to pg_parse_lsn(), as follows?

You're right, that is better. v2 attached does it that way in
backup_label.c, and applies the same approach in pg_rewind's
timeline.c, so the patch no longer touches src/common at all.

> As for pg_parse_lsn_prefix(), it seems to accept 0/0x3000000 as 0/0,
> for example. So, *if* we use pg_parse_lsn_prefix(), we'd also need to
> verify that the next character is expected?

Right about the helper on its own. In v1 both call sites checked the
next character -- in backup_label.c, the terminator check that was
already there -- so neither tool accepted that input. In v2 the
whole token goes to pg_parse_lsn(), so there is no such check left
for a caller to get wrong.

> I'm not sure if it's really worth adding these TAP tests.

Agreed. Dropped in v2.

make check-world passes here.
I'd appreciate any feedback.

Regards,
Zexin Li