Hi@vlsi, those are amazing news!

Is there any explanation though why it works onv42.7.4 but not on others?
I tried to look into the changes and changelog but can't really understand what/when this problem was introduced.

LGTM, this will be difficult to test.

I'm leaning towards adding a test with mock that triggers an exception from.cancel()
Will try adding it shortly.

Is there any explanation though why it works on v42.7.4 but not on others?

bac3d0a landed at 42.7.6, and it changedint tobyte[]. Previously, an unsetcancelKey was just0, so it did not cause any harm. After PR#3592 thenullbyte[] could cause NPE.
Interestingly,castNonNull caused NPE, so writing code in a way that does not requirecastNotNull seems the right way to go.

At the same time, backend should always supplycancel key in the startup messages, so I don't understand how is it possible that you havenullcancelKey. I wonder if you could capture logging fororg.postgresql.core.QueryExecutorBase in order to check if it does indeed end up with null cancel keys.
Do you use a load balancer?

It does not explain the reason 42.7.5 fails though. Just to double-check: does 42.7.5 fail for you as well?

I'm leaning towards adding a test with mock that triggers an exception from.cancel() Will try adding it shortly.

Is there any explanation though why it works on v42.7.4 but not on others?

bac3d0a landed at 42.7.6, and it changedint tobyte[]. Previously, an unsetcancelKey was just0, so it did not cause any harm. After PR#3592 thenullbyte[] could cause NPE. Interestingly,castNonNull caused NPE, so writing code in a way that does not requirecastNotNull seems the right way to go.

At the same time, backend should always supplycancel key in the startup messages, so I don't understand how is it possible that you havenullcancelKey. I wonder if you could capture logging fororg.postgresql.core.QueryExecutorBase in order to check if it does indeed end up with null cancel keys. Do you use a load balancer?

It does not explain the reason 42.7.5 fails though. Just to double-check: does 42.7.5 fail for you as well?

We bumped from~.4 to~.7 so I can't say if the~.5 works or not.

Some info that may or may not help:

• yes, we have as LB and RDS Proxy
• we are using a mix of quarkus/pure java, meaning our connections are also a mix of hikari and agroal

Regarding capturing the log fororg.postgresql.core.QueryExecutorBase, that is a tricky one since the bump caused a couple of hours long outage on our prod
Also, quite interesting, it does not happen on dev - probably related to the timeout after all, it would at least explain it

that is a tricky one since the bump caused a couple of hours long outage on our prod

Sorry to hear that.
I mean the log would be helpful for either old or new (after the cancellation issue gets fixed) version.
The old (e.g. 42.7.4) logs the key:https://github.com/pgjdbc/pgjdbc/blob/REL42.7.4/pgjdbc/src/main/java/org/postgresql/core/QueryExecutorBase.java#L190

I wonder ifckey={1} comes out as0.
Sure there's no hurry to logging it, however, if the cancellation key is not set, then it might be the cancellation does not work in your case. It might be caused by the balancer chewing the cancellation key from within the startup message.

An alternative option would be trying to executepg_sleep(..)including your balancers and proxies, to verify if you can getPSQLException: ERROR: canceling statement due to user request whensetQueryTimeout(...) kicks in.