Re: Designing a better connection pool for psycopg3

In my opinion it is not only static vs dynamic,
> Exclusive connections?> What to do in case of connection failure?
> A first step towards a sane behaviour could be to die early, on startup, if the connection is not working when the first pool population is done
Agree.

BTW, at which moment will the driver be trying to connect? At pool

initialization or on first "getconn()"?

> What if the database is missing in action during the program lifetime? Following connection attempts may be repeated, with an exponential backoff, until dying after a few minutes of fruitless attempts
Yes, I would prefer exponential backoff, with a timeout prior to "panic" callback.
Preferably, both configurable.

> Connections usage pattern
I don't see cases where an application should bother about it,
choose whatever is better for your implementation. And yes, stack
looks reasonable.

> 'minconn', Proposed default: 4
Many services and applications do not really need many connections
but would like to benefit from automatic reconnections. So the default
is questionable, as many people will leave it unchanged.

> "get_info()"
One thing that comes into my head every time I use connection pools
is how many are really needed for my application. Usually it is adjusted
experimentally or using some performance tests. Can you collect and
provide some stats to get more insights on that? I see you want to
expose some in "get_info()", which exactly? E.g. number of times
the max limit was hit, current number of connections acquired?

> 'max_lifetime_sec'
Why is it necessary at all? Does a connection get rotten with time?
As I understand, you are planning to check a connection state in
background. As long as it is OK, what is the need to replace it?

> num_workers, default: 3
Assuming every worker does the same job, is there really the amount
of work for three workers?

"get_maintenance_task()"
This API seems to be too advanced, in what cases you see a sane use case for it?

Thank you,

Vladimir