Re: BUG #18534: ERROR: portal "C_n" does not exist type of error getting thrown.
| От | Aleksander Alekseev |
|---|---|
| Тема | Re: BUG #18534: ERROR: portal "C_n" does not exist type of error getting thrown. |
| Дата | |
| Msg-id | CAJ7c6TNqqZ+99vfHohdQUZZfm5y_zCSNkFrerSfaPw7-E8oc+w@mail.gmail.com обсуждение исходный текст |
| Ответ на | BUG #18534: ERROR: portal "C_n" does not exist type of error getting thrown. (PG Bug reporting form <noreply@postgresql.org>) |
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: