Message-ID: <gh-pgjdbc-pgjdbc-4016-c4229253551@github.com>
From: "davecramer (@davecramer)" <noreply+davecramer@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Sat, 11 Apr 2026 10:15:49 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #4016: feat: harden protocol reader against desynced streams (#4015)
In-Reply-To: <gh-pgjdbc-pgjdbc-4016@github.com>
References: <gh-pgjdbc-pgjdbc-4016@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: davecramer
X-GitHub-Comment-Id: 4229253551
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 4016
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4016#issuecomment-4229253551
Content-Type: text/plain; charset=utf-8

> This is still WIP, however, I would like to know if we want adding more debug information to "desync detected" exception messages.
> 
> For instance, here's one of the failures:
> 
> ```
>         Caused by: java.io.IOException: Protocol error. C-string exceeds remaining message budget of 30 bytes.
>             at org.postgresql.core.VisibleBufferedInputStream.scanCStringLength(VisibleBufferedInputStream.java:398)
>             at org.postgresql.core.PGStream.receiveBoundedCanonicalStringIfPresent(PGStream.java:711)
>             at org.postgresql.core.v3.QueryExecutorImpl.receiveParameterStatus(QueryExecutorImpl.java:3103)
>             at org.postgresql.core.v3.QueryExecutorImpl.readStartupMessages(QueryExecutorImpl.java:3080)
>             at org.postgresql.core.v3.QueryExecutorImpl.<init>(QueryExecutorImpl.java:237)
> ```
> 
> Should we add something like "the latest bytes are ..."? I have mixed feelings about it:
> 
> 1. It might be a security issue (e.g. the bytes might easily contain sensitive info)
> 2. It might be useless for the analysis
> 3. It might be helpful for the analysis (e.g. like in [receiveTupleV3 allocates huge byte[] due to misread 4-byte field length under high concurrency #4015](https://github.com/pgjdbc/pgjdbc/issues/4015))

Not sure how it would be helpful. I would imagine that replicating such a failure would be difficult. These failures should be quite random so I doubt that subsequent failures would be the same. Plus I agree with the security issue.