Port to psycopg3

Cc. @marmoute

assigned to @olasd

Jenkins job DPROV/gitlab-builds #216 succeeded in 3 min 36 sec.
See Console Output, Blue Ocean and Coverage Report for more details.

approved this merge request

We need to mix this with !199 (merged) for better result. I'll look into that tomorrow/monday.

My MR is not a superset of this one, except for the pool.wait() usage that I asked about.

Do we really need this here? Because the test does not seems to depends on it, and in most case we don't do it (e.g. the scheduler does it, but the storage don't).

If we really want this, self._pool.wait() seems more appropriate (it open a bit more connections, but the semantic seems more appropriate), and we should consider doing it in all case too.

(side note, this pattern of db/connection pool seems repeated in various places and could probably be factored out for consistency).

Maybe we should offer a wait function on the PostgresqlProvenance object itself to let the caller wait explicitly if the context warrants it?

This is the only way to check whether the configuration of the database is correct or not (rather than have it deferred to the first postgresql access), so I think we should do that everywhere, yeah.

I just realized that the open=False is changing the behavior making it more needed. So I'll add it everywhere (in addition to open=False).

Ah! Yeah, you're right. The problem with open=True was two-fold:

• You get the default 30 second timeout even on the initial connection (which is probably okay to recover from transient issues, but not great for initial connection checking)
• But open=True tells the /background/ workers to connect, so you need to call wait anyway if you want an exception on a badly configured connection (and you'll only get it after the 30s timeout)

So creating the pool with open=False + an explicit open(wait=True, timeout=1) ended up being the best compromise.

I would lean toward using open=True to preserve what we are currently doing in the storage so far. Are you saying we need open=True and a call to wait to make sure we get a proper error?

We want a short timeout on initialization then a longer timeout on operation, so we can't use open=True.

!199 (merged) should be ready now.

mentioned in merge request !199 (merged)

Closed in favor of !199 (merged)

closed