Message-ID: <gh-pgjdbc-pgjdbc-4013@github.com>
From: "bilalshehata (@bilalshehata)" <noreply+bilalshehata@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Wed, 08 Apr 2026 03:37:44 +0000
Subject: [pgjdbc/pgjdbc] PR #4013: fix: initialize maxBufferedRecvBytes from actual socket receive buffe…
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Id: 30518704
X-GitHub-Author-Login: bilalshehata
X-GitHub-Issue: 4013
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-State: closed
X-GitHub-Type: pull_request
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4013
Content-Type: text/plain; charset=utf-8

(first open source contribution to this repo just fixing a bug that was really bothering me - any feedback is appreciated ) 

Trying to fix this bug http://github.com/pgjdbc/pgjdbc/issues/194 
The driver has a hardcoded 64KB threshold (`MAX_BUFFERED_RECV_BYTES`) for deciding when to flush during batch execution. The idea is to avoid a deadlock where both sides block waiting for the other to drain their buffers. But if the actual OS socket receive buffer is smaller than 64KB, the driver pipelines too many queries before flushing and you still get the deadlock.

This reads the real socket receive buffer size at connection time and uses that as the threshold instead. If it can't be read, it falls back to the old 64KB default.

### All Submissions:

* [x] Have you followed the guidelines in our [Contributing](https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md) document?
* [x] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change?

<!-- You can erase any parts of this template not applicable to your Pull Request. -->

### New Feature Submissions:

1. [x] Does your submission pass tests?
2. [x] Does `./gradlew styleCheck` pass ?
3. [x] Have you added your new test classes to an existing test suite in alphabetical order?

### Changes to Existing Features:

* [x] Does this break existing behaviour? If so please explain.
* [x] Have you added an explanation of what your changes do and why you'd like us to include them?
* [x] Have you written new tests for your core changes, as applicable?
* [x] Have you successfully run tests with your changes locally?