Thread: BUG #18534: ERROR: portal "C_n" does not exist type of error getting thrown.

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.

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