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

On Sun, Aug 10, 2026, Fujii Masao wrote:
> The main change from v2 is that pg_lsn_in_safe() now also uses
> pg_parse_lsn(), leaving only the backend-specific soft-error handling
> there. This avoids duplicating the LSN syntax checks.

Thank you for the review. v3 looks good to me.

Regards,
Zexin Li

On Mon, Aug 10, 2026 02:47 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Fri, Aug 7, 2026 at 10:58 AM Zexin Li <lizi(dot)openmind(at)gmail(dot)com> wrote:
> > The helper is pg_parse_lsn() in the new src/common/pg_parse_lsn.c,
> > with the same rules as the backend's pg_lsn_in_safe(): one to eight
> > hex digits, a slash, one to eight hex digits, and nothing else.
> > pg_waldump's static helper from v1 moves there, and pg_recvlogical
> > (-I/-E) and pg_receivewal (-E) now go through it as well.
>
> > * The backend's pg_lsn_in_safe() is left untouched for now.
>
> Thanks for updating the patch!
>
> Attached is a revised version. It keeps the v2 approach of adding
> pg_parse_lsn() in src/common and using it for user-supplied LSN
> command-line options in pg_waldump, pg_recvlogical, and
> pg_receivewal.
>
> The main change from v2 is that pg_lsn_in_safe() now also uses
> pg_parse_lsn(), leaving only the backend-specific soft-error handling
> there. This avoids duplicating the LSN syntax checks.
>
> Thought?
>
> Regards,
>
> --
> Fujii Masao
>