Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Driver version 42.5.2 executes a query for every new connection #2746

Closed
olavloite opened this issue Feb 2, 2023 · 3 comments
Closed

Driver version 42.5.2 executes a query for every new connection #2746

olavloite opened this issue Feb 2, 2023 · 3 comments

Comments

@olavloite
Copy link
Contributor

Describe the issue
Creating a new connection in version 42.5.2 will always execute the following query on a default PG installation:

SELECT pg_type.oid, typname   FROM pg_catalog.pg_type   LEFT   JOIN (select ns.oid as nspoid, ns.nspname, r.r           from pg_namespace as ns           join ( select s.r, (current_schemas(false))[s.r] as nspname                    from generate_series(1, array_upper(current_schemas(false), 1)) as s(r) ) as r          using ( nspname )        ) as sp     ON sp.nspoid = typnamespace  WHERE typname = ?  ORDER BY sp.r, pg_type.oid DESC LIMIT 1

This makes creating a new connection more expensive than in previous versions.

See cb78d0e#r99017399 for more details.

Driver Version?
42.5.2

Java Version?
open-jdk17

OS Version?
MacOS

PostgreSQL Version?
13.4

To Reproduce
Create a new JDBC connection to a standard PG server.

Expected behaviour
Creating a new connection should not automatically execute any queries.

@olavloite olavloite changed the title Driver executes a query for every new connection Driver version 42.5.2 executes a query for every new connection Feb 2, 2023
olavloite referenced this issue Feb 2, 2023
…ly (Issue #2554) (#2556)

The driver would automatically register types for binary transfer when calling
con.unwrap(PGConnection.class).addDataType(String, Class)

Fixes #2554
@davecramer
Copy link
Member

thanks!

@davecramer
Copy link
Member

So the question is: how to fix this?
One thought is that we have known oid's for all the built in types. we can preload the cache with known oid's
I'm not sure how safe that is though

davecramer added a commit to davecramer/pgjdbc that referenced this issue Feb 2, 2023
davecramer added a commit that referenced this issue Feb 3, 2023
* Add box to TypeInfoCache, fixes Issue #2746

* use semi-colon delimiter for box type

* Fix: regression in PgResultSet LONG_MIN copy paste error fixes Issue #2748 (#2749)
@davecramer
Copy link
Member

fixed with #2747

davecramer added a commit to davecramer/pgjdbc that referenced this issue Feb 20, 2023
* Add box to TypeInfoCache, fixes Issue pgjdbc#2746

* use semi-colon delimiter for box type

* Fix: regression in PgResultSet LONG_MIN copy paste error fixes Issue pgjdbc#2748 (pgjdbc#2749)
davecramer added a commit that referenced this issue Feb 20, 2023
* Add box to TypeInfoCache, fixes Issue #2746 (#2747)

* use semi-colon delimiter for box type

* fix: fix testGetSQLTypeQueryCache by searching for xid type. We used to search for box type but it is now cached (#2810)

fix: OidValueCorrectnessTest BOX_ARRAY OID, by adding BOX_ARRAY to the oidTypeName map
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants