Message-ID: <gh-pgjdbc-pgjdbc-3530-c3203929007@github.com>
From: "wangkaish (@wangkaish)" <noreply+wangkaish@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Wed, 20 Aug 2025 02:19:19 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3530: JDBC Shared Timer set to cancelled
In-Reply-To: <gh-pgjdbc-pgjdbc-3530@github.com>
References: <gh-pgjdbc-pgjdbc-3530@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: wangkaish
X-GitHub-Comment-Id: 3203929007
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 3530
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3530#issuecomment-3203929007
Content-Type: text/plain; charset=utf-8

@davecramer Yes, OOM is a special case — it signals memory allocation failure and starts throwing exceptions. Normally, the temporary variables allocated in the thread would then be reclaimed, and the system should have a chance to recover.

The problem we are facing is that even after memory usage drops, the system still cannot recover. We have no other workaround at the moment, and may need to consider implementing our own delayed scheduler to handle queryTimeout.