START_REPLICATION silently truncates an overlong LSN component

Hi, I found a potential bug in PostgreSQL's replication command parser where `START_REPLICATION` accepts an LSN whose high component contains more than eight hexadecimal digits and silently truncates it to a different WAL location, rather than rejecting it. Description: The replication command `START_REPLICATION` accepts an LSN in the format `X/Y`, where `X` and `Y` are hexadecimal numbers. The parser accepts an overlong high component (e.g., `123456789/0`) and silently maps it to `23456789/00000000` by truncating the excess digit. This means the server starts replication from a different WAL location than the user requested, without any error or warning. PostgreSQL version: - PostgreSQL 19beta3 (Docker-based runtime) - Source commit: not recorded in the original report - Build relationship: the tested image was not an exact-HEAD build Environment: - Docker-based PostgreSQL 19beta3 runtime - Replication connection privileges required - No special server configuration beyond standard replication setup Steps to Reproduce: Run the following command using a replication connection: ```bash psql "user=postgres dbname=postgres replication=database" \  -c 'START_REPLICATION 123456789/0;'

Then inspect the PostgreSQL server log. For a filing-quality rerun, enable log_error_verbosity=verbose and capture the complete relevant log section.

Actual Result:

The server log identifies a different starting point. For the command above, the log shows:
text

requested starting point 23456789/00000000 ... STATEMENT: START_REPLICATION 123456789/0;

The original 123456789/0 was interpreted as 23456789/00000000, with the high component truncated from nine digits to eight.

Expected Result:

The backend should reject an LSN component longer than eight hexadecimal digits with a syntax error or a specific "invalid LSN" error. It should not silently convert it to another WAL location.

Reproduction Frequency:

Positive reproduction: 2/2 on PostgreSQL 19beta3

Negative control: START_REPLICATION 0/0 remained 0/0

Additional Observations:

The issue likely originates from the replication scanner accepting an unrestricted hexadecimal token and parsing it into a 32-bit destination without checking the component width or whether the conversion was lossless. This could lead to replication starting from an unexpected LSN, potentially causing data inconsistencies or confusion during recovery.

I searched the public PostgreSQL bug archives and did not find any report specifically addressing LSN component overflow or truncation in START_REPLICATION. Please confirm whether this is considered a bug.

♂π≌26218
1991230470(at)qq(dot)com