Replication misreads the stream after a backend message larger than the read buffer #6699

A backend message other than CopyData that is longer than the read buffer (8 KB by default), e.g. a long notice, makes the connector switch to a bigger buffer for the rest of the session (NpgsqlConnector.cs:1523-1545). The replication stream and the pgoutput decoder keep the buffer they captured before (ReplicationConnection.cs:448, PgOutputAsyncEnumerable.cs:114, TupleEnumerator.cs:24, ReplicationValue.cs:34). After such a message they read past what the connector has already received, so they misparse the stream or wait for data that has already arrived. For example, since PostgreSQL 15 a publication row filter such as numnode(websearch_to_tsquery('simple', q)) > 0 makes the walsender raise a notice that repeats the whole input when q has no lexemes (postgres tsquery.c:882-884). With more than about 8 KB of whitespace in q, that notice is longer than the buffer, and on PostgreSQL 18.6 and 15.19 main failed after the first row with "Unknown replication message code 'd'".

A related problem: the bigger buffer's array comes from ArrayPool<byte>.Shared (NpgsqlReadBuffer.cs:113, 397-400), and a broken connector returns it to the pool (NpgsqlConnector.cs:2448-2453, NpgsqlReadBuffer.cs:784-785), so a message held across a break can read another renter's bytes. On main this happens when the switch came before START_REPLICATION, e.g. through a long SHOW result on the same connection, because the stream then captures the bigger buffer (ReplicationConnection.cs:448). So a broken connector shouldn't return that array to the pool. With main on PostgreSQL 18.6, a 20000-character SHOW result before START_REPLICATION, a held XLogData and pg_terminate_backend made the held XLogData read 0xEE, written by an injected next renter.

Rare, since walsenders seldom send such messages while streaming. The same code is on the 8.0, 9.0 and 10.0 hotfix branches.