Message-ID: <gh-pgjdbc-pgjdbc-4014-c4275489393@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Sun, 19 Apr 2026 08:13:25 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #4014: fix: restore pre-describe for generated-key batches
In-Reply-To: <gh-pgjdbc-pgjdbc-4014@github.com>
References: <gh-pgjdbc-pgjdbc-4014@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: vlsi
X-GitHub-Comment-Id: 4275489393
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 4014
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4014#issuecomment-4275489393
Content-Type: text/plain; charset=utf-8

I made the needed changes, notably:
1) The initial revert of d232e605de960f3a8ca2dfef4974dbe546b860bb did not account for `statement.closeOnCompletion()` (it was a long-standing bug), so I added `DiscardResultHandler` to avoid creating unwanted resultsets
2) The test used `text` column, and there was no way to estimate the max number of bytes returned. I switched to `varchar(N)` in tests, and added `varchar` estimator (it was not really working previously), see `estimateMaxLength`
3) Previously `flushIfDeadlockRisk` could issue `sync` even before the first query which apparently makes no sense. In my tests the logic works as expected, and it attempts to keep receiving buffer under 64000.

For the reference, 
1) I've checked `getReceiveBufferSize()` and it easily grows to 400KiB, no matter if I configure it explicitly or not
2) I've tested different combinations for `MAX_BUFFERED_RECV_BYTES` and `receiveBufferSize`, and the current 64000 is still the sweet spot for my machine (Apple M1, PostgreSQL in Docker)

---

I will let the dust to settle, and it would be great if somebody else could review it as well.