Message-ID: <gh-pgjdbc-pgjdbc-3778-c3215097901@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Fri, 22 Aug 2025 17:31:16 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #3778: fix: avoid IllegalStateException: Timer already cancelled  when StatementCancelTimerTask.run throws a runtime error
In-Reply-To: <gh-pgjdbc-pgjdbc-3778@github.com>
References: <gh-pgjdbc-pgjdbc-3778@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: vlsi
X-GitHub-Comment-Id: 3215097901
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2025-08-22T17:53:27Z
X-GitHub-Issue: 3778
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3778#issuecomment-3215097901
Content-Type: text/plain; charset=utf-8

> 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 if `ckey={1}` comes out as `0`.
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 execute `pg_sleep(..)` **including** your balancers and proxies, to verify if you can get `PSQLException: ERROR: canceling statement due to user request` when `setQueryTimeout(...)` kicks in.