Hi,
> The following bug has been logged on the website:
>
> Bug reference: 18534
> Logged by: madhuri nehe
> Email address: nehemadhuri@gmail.com
> PostgreSQL version: 15.3
> Operating system: Linux
> Description:
>
> 1. This issue occurs in multithreaded application.
> 2. We retrieve records from a single table and store them in the ResultSet
> object of JDBC.
> 3. To read the records sequentially from the ResultSet object, we employ the
> rSet.next() method for iteration.
> 4. We are encountering a sporadic portal exception triggered by the
> rSet.next() method call.
> 5. We have examined all potential causes, such as verifying the executed
> query, checking if the ResultSet cursor is open or closed, ensuring the
> database connection object is active, and confirming the prepared statement
> cursor’s status. No issues have been detected. Also, ResultSet is not being
> accessed by multiple threads simultaneously.
>
> We've been thorough in our search for the cause of the issue but haven't
> found anything yet.
This could indicate either a bug in PostgreSQL code or in the
application. For instance if there is a pool of JDBC objects and one
of the objects is not cleaned up properly before returning to a pool
(i.e. because of a thrown exception) the next user of an object can
get it in an inconsistent state, where the object believes there is an
open portal called "C_n" while PostgreSQL is not aware of it. If you
use a connection pooler like PgBouncer this will complicate the
situation even further because PgBouncer will allocate one connection
per transaction or per statement depending on the settings.
Honestly, it's very unlikely that a named portal would silently
disappear from a hash table on the PostgreSQL side, but who knows.
If you could provide a minimal example of a program and database
scheme that reproduces the issue that would be very helpful. Otherwise
there is little we can do.
--
Best regards,
Aleksander Alekseev
