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

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: nehemadhuri(at)gmail(dot)com
Subject: Re: BUG #18534: ERROR: portal "C_n" does not exist type of error getting thrown.
Date: 2024-07-15 11:23:03
Message-ID: CAJ7c6TNqqZ+99vfHohdQUZZfm5y_zCSNkFrerSfaPw7-E8oc+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

> The following bug has been logged on the website:
>
> Bug reference: 18534
> Logged by: madhuri nehe
> Email address: nehemadhuri(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Aleksander Alekseev 2024-07-15 12:16:09 Re: BUG #18536: Using WITH inside WITH RECURSIVE triggers a "shouldn't happen" error
Previous Message Etsuro Fujita 2024-07-15 10:51:03 Re: BUG #17889: Invalid cursor direction for a foreign scan that reached the fetch_size (MOVE BACKWARD ALL IN cX)