Fix race condition with use of PgVectorAgroalPoolInterceptor

[geoand]

Prior to this, the application could open a connection that did not use the interceptor and then try and
reuse that connection against a PgVector database
without having the interceptor (as Agroal
would not take it into account because the connection was already open)

• Fixes: Using PGVector storage with Plain Hibernate Postgres breaks the Embeddings implementation #726

[geoand]

Once this is in, I am going to do a release of 0.16.1 as this could easily be a blocker for development.

@jmartisk I think this interceptor should not be applied to the prod run, WDYT?

[jmartisk]

@jmartisk I think this interceptor should not be applied to the prod run, WDYT?

By that you mean connections for any other datasource than the one configured for embedding storage? If so, then yeah.

[geoand]

By that you mean connections for any other datasource than the one configured for embedding storage

I mean that from what I understand, this interceptor creates a type, which I think should not never be done by the framework in production (but it currently is).

[jmartisk]

By that you mean connections for any other datasource than the one configured for embedding storage

I mean that from what I understand, this interceptor creates a type, which I think should not never be done by the framework in production (but it currently is).

But how else should it work? The application would have to register a similar interceptor by itself... Which would be annoying

[geoand]

But how else should it work? The application would have to register a similar interceptor by itself... Which would be annoying

My point is that a production database would already be setup properly - in the same way you don't expect the application to create your relational schema

[jmartisk]

But how else should it work? The application would have to register a similar interceptor by itself... Which would be annoying

My point is that a production database would already be setup properly - in the same way you don't expect the application to create your relational schema

For the database, sure, but this is not about the database, this is about registering an extension of the JDBC driver (client)

[geoand]

Ah okay, I misunderstood it's functionality then - my bad!

[geoand]

So this PR is ready then

[jmartisk]

Ah, so IIUC it seems that actually the CREATE EXTENSION command is indeed server-side...
But the interceptor also calls

PGvector.addVectorType(connection);

which is the client-side setup.
So perhaps you're right and we could skip the CREATE EXTENSION part of the interceptor in production mode.

[jmartisk]

The question is if it's really a big burden to have it executed, just to simplify things

[geoand]

Thanks for checking further.

Let's leave it as is for now, and I'll open a new issue to keep the enhancement in mind for later.
I am going to assume we will need it because I believe lots of applications won't have the karma to do CREATE EXTENSION