Subject: [pgjdbc/pgjdbc] PR #2525: fix: support queries with up to 65535 (inclusive) parameters

From: "vlsi (@vlsi)" <[email-masked]>
Date: Tue, 31 May 2022 08:15:27 +0000

Previously the execution failed with "Tried to send an out-of-range integer as a 2-byte value"
when the user attempted executing a query with more than 32767 parameters.

Technically speaking, the wire protocol limit is 2-byte-unsigned-int,
so we should support 65535 parameters.

In practice, simple mode (preferQueryMode=simple) allows executing queries
with an arbitrary number of parameters, however, that escape hatch is not recommended
as it still has limits on the SQL length, and it would likely be slow.

fixes #1311

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Tue, 31 May 2022 12:27:22 +0000

(on pgjdbc/src/main/java/org/postgresql/core/PGStream.java)

are we allowed negative values here ? Should this be < 0 || > 65535 ?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Tue, 31 May 2022 12:54:04 +0000

Indeed. Negatives shall not pass

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 01 Jun 2022 10:14:36 +0000

I just pushed revert commits to check if the CI duration improves.

In an unlikely case, "fix close refcursors" caused cursor leaks or something like that.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 01 Jun 2022 11:33:00 +0000

Rolling back "fix close refcursors" reduces CI duration from 3h50m to 50min.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 01 Jun 2022 11:51:29 +0000

Ok, the reason is "org.postgresql.test.jdbc2.RefCursorFetchTest |   | PASSED | 2h 57m 24.946s"

In other words, it does not look like a code regression, rather it looks like RefCursorFetchTest is extremely slow for unknown reasons.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 Jun 2022 12:20:05 +0000

> In other words, it does not look like a code regression, rather it looks like RefCursorFetchTest is extremely slow for unknown reasons.

that seems rather odd ?

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 01 Jun 2022 13:10:52 +0000

It all means "fix close refcursors" was OK, and there's something else going slow with CI env.

The worst thing is that if I launch just `org.postgresql.test.jdbc2.RefCursorFetchTest` in Actions, then it takes ~16 or so seconds.

So it looks like some of the tests before RefCursorFetchTest triggers a bad condition, so subsequent tests become slow.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 01 Jun 2022 13:16:06 +0000

we can try to ask for support from github. They have been helpful in the past on security isssues.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 01 Jun 2022 14:29:41 +0000

Finally, I nailed it: https://github.com/pgjdbc/pgjdbc/commit/82dbbe46002d43298ed4ff1df26623f9cb51effd#diff-dd8064c49349abfe7ba0b6e2d65ebb7d89600239c982dd0556bdace3765f751cL24-L25

`SendRecvBufferSizeTest` had `System.setProperty("sendBufferSize", "1024"); System.setProperty("receiveBufferSize", "1024");`

That caused all the test after `SendRecvBufferSizeTest` to use the small buffer size, which caused slow processing of large requests/responses.

Just in case you wonder, the trace log does show buffer sizes:

```
2022-05-31 20:10:33 FINE org.postgresql.Driver connect Connecting with URL: jdbc:postgresql://localhost:5432/test?ApplicationName=Driver Tests&loggerLevel=OFF&loggerFile=target/pgjdbc-tests.log
2022-05-31 20:10:33 FINE org.postgresql.jdbc.PgConnection <init> PostgreSQL JDBC Driver 42.3.7-SNAPSHOT
2022-05-31 20:10:33 FINE org.postgresql.jdbc.PgConnection setDefaultFetchSize   setDefaultFetchSize = 0
2022-05-31 20:10:33 FINE org.postgresql.jdbc.PgConnection setPrepareThreshold   setPrepareThreshold = 5
2022-05-31 20:10:33 FINE org.postgresql.core.v3.ConnectionFactoryImpl openConnectionImpl Trying to establish a protocol version 3 connection to localhost:5432
2022-05-31 20:10:33 FINE org.postgresql.core.v3.ConnectionFactoryImpl tryConnect Receive Buffer Size is 1,152
2022-05-31 20:10:33 FINE org.postgresql.core.v3.ConnectionFactoryImpl tryConnect Send Buffer Size is 2,304
2022-05-31 20:10:33 FINEST org.postgresql.core.v3.ConnectionFactoryImpl enableSSL  FE=> SSLRequest
2022-05-31 20:10:33 FINEST org.postgresql.core.v3.ConnectionFactoryImpl enableSSL  <=BE SSLOk
2022-05-31 20:10:33 FINE org.postgresql.ssl.MakeSSL convert converting regular socket connection to SSL
```

---

From: "pwagland (@pwagland)" <[email-masked]>
Date: Tue, 14 Jun 2022 07:20:32 +0000

(on pgjdbc/src/main/java/org/postgresql/jdbc/PgPreparedStatement.java:102)

This _should_ have been:
```java
GT.tr("PreparedStatement can have at most {0} parameters. Please consider using arrays, or splitting the query in several ones, or using COPY. Given query has {1} parameters",
```

---

From: "jarvis24young (@jarvis24young)" <[email-masked]>
Date: Thu, 15 Jan 2026 03:49:16 +0000

im wondering where it shows the  the wire protocol limit is 2-byte-unsigned-int instead of 2-byte-int

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 15 Jan 2026 11:02:08 +0000

> im wondering where it shows the the wire protocol limit is 2-byte-unsigned-int instead of 2-byte-int

all of the protocol docs are on the postgresql website.