Subject: [pgjdbc/pgjdbc] PR #4013: fix: initialize maxBufferedRecvBytes from actual socket receive buffe…

From: "bilalshehata (@bilalshehata)" <[email-masked]>
Date: Wed, 08 Apr 2026 03:37:44 +0000

(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?

---

From: "bilalshehata (@bilalshehata)" <[email-masked]>
Date: Wed, 08 Apr 2026 09:43:13 +0000

@davecramer wondering if you could retrigger the CI for this one, just needed to adjust my unit test

---

From: "bilalshehata (@bilalshehata)" <[email-masked]>
Date: Wed, 08 Apr 2026 09:58:36 +0000

@davecramer  i removed the before test entirely, the deadlock doesn't seem to be reliably reproducable in all environments, I assume the CI has some sort of loop back networking which  makes it behave differently to real world behaviours. I have left the post-fix tests in place

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 08 Apr 2026 09:59:49 +0000

(on pgjdbc/src/test/java/org/postgresql/test/jdbc2/BatchDeadlockTest.java)

change this to 2026

---

From: "bilalshehata (@bilalshehata)" <[email-masked]>
Date: Wed, 08 Apr 2026 10:00:49 +0000

Done 👍

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 08 Apr 2026 10:03:03 +0000

(on pgjdbc/src/test/java/org/postgresql/test/jdbc2/BatchDeadlockTest.java:191)

Can we avoid private/final field modification in tests?

---

From: "bilalshehata (@bilalshehata)" <[email-masked]>
Date: Wed, 08 Apr 2026 11:46:53 +0000

@davecramer  could you rerun the test suite, thanks!

---

From: "bilalshehata (@bilalshehata)" <[email-masked]>
Date: Wed, 08 Apr 2026 12:16:32 +0000

@vlsi that is a good point, let me reconsider the approach -> I Suspect maybe we can make Pgstatement code more precise about the buffers rather than having to do this guess work when it comes to flushing the buffers