| From: | Dave Cramer <davecramer(at)postgres(dot)rocks> |
|---|---|
| To: | Sehrope Sarkuni <sehrope(at)jackdb(dot)com> |
| Cc: | Blake McBride <blake1024(at)gmail(dot)com>, pgsql-jdbc(at)lists(dot)postgresql(dot)org |
| Subject: | Re: JDBC: ERROR: portal "C_2" does not exist |
| Date: | 2022-03-11 19:29:28 |
| Message-ID: | CADK3HHLU0WyDe5_+tRY-=nyDDTndqQ+Vfw9Su1ba9zggGVW-_w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Hi Blake
On Fri, 11 Mar 2022 at 14:04, Sehrope Sarkuni <sehrope(at)jackdb(dot)com> wrote:
> When auto commit is diabled and using a non-zero fetch size, the pgjdbc
> driver creates a portal to read the query results from the server in chunks
> of fetch size. The portals have a string identifier and the driver
> generates them sequentially per connection with a "C_" prefix, so "C_1", "
> C_2", "C_3", ... etc.
>
> As you read results via ResultSet.next(), the driver checks if it has the
> next row already buffered. If not, it reads from the named portal to
> retrieve the next chunk of fetchSize quantity of rows.
>
> A fetch size of 50 and the error happening at row 51 likely means that
> something either closed the portal or the connection itself is not correct.
>
> Are you using a connection pool like pgbouncer in between your Java
> application and the database server?
>
> If so, the connection pooler must be transaction aware to ensure that the
> same connection is used throughout the entire transaction.
>
Actually the recommendation for pgbouncer and I presume other poolers is to
turn off prepared statements
Disabling prepared statements in JDBC
The proper way to do it for JDBC is adding the prepareThreshold=0 parameter
to the connection string.
Dave
>
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Blake McBride | 2022-03-11 19:56:02 | Re: JDBC: ERROR: portal "C_2" does not exist |
| Previous Message | Sehrope Sarkuni | 2022-03-11 19:04:21 | Re: JDBC: ERROR: portal "C_2" does not exist |