Message-ID: <gh-pgjdbc-pgjdbc-3889-c3622311198@github.com>
From: "manav-yb (@manav-yb)" <noreply+manav-yb@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Sun, 07 Dec 2025 15:16:56 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3889: JDBC Not Sending CLOSE packet
In-Reply-To: <gh-pgjdbc-pgjdbc-3889@github.com>
References: <gh-pgjdbc-pgjdbc-3889@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: manav-yb
X-GitHub-Comment-Id: 3622311198
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2025-12-07T15:17:20Z
X-GitHub-Issue: 3889
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3889#issuecomment-3622311198
Content-Type: text/plain; charset=utf-8

Expecting CLOSE to validate pstmt.close() is sent. 
But from server point of view, not sending actual CLOSE message, I see 2 problems and solutions as well, please correct me if I'm wrong.
1) There can be a resource leak if lot of prepared statements unused been prepared on a long lived backend. But JDBC is configuring it with help of preparedStatementCacheQueries, developer can set it to 0 but he/she won't get advantage of shared prepared statements.
2) On schema change it can cause an Error - "Cached plan must not change result type". Because CLOSE has not  been explicitly send by driver even application has written pstmt.close(). But given JDBC has a the mechansim to retry (when it receives such error) it silently by sending actual CLOSE message followed by new PARSE packet. 

Are there are any other known problems which has or has not workaround.