Re: START_REPLICATION silently truncates an overlong LSN component

Hi Kuroda-san, Fujii-san,

Thanks for updating the patch set. I tested the two remaining ones on my
system. They apply cleanly and check-world passes.

Patch 0001
==========

I have just a small comment on the moved MAXPG_LSNLEN. It's currently a
hard-coded 17. It could make sense to export MAXPG_LSNCOMPONENT as well
and define MAXPG_LSNLEN as (2 * MAXPG_LSNCOMPONENT + 1), which would
document where the value comes from.

Patch 0002
==========

Kuroda-san wrote in the v5 mail:

> I also attached the test code to check invalid strings can be
rejected, see 0002.
> I'm not intended to be pushed.

I think this test is worth committing. As far as I can see, nothing else
covers the "this is an incremental backup, not a data directory" error,
and the new LSN checks would otherwise remain untested. However, we test
only an overlong high component. It could make sense to add this test
for the low component as well (e.g., using 0/123456789).

Best regards
Jan

--
Jan Nidzwetzki
PlanetScale Postgres Core Team