I think library users should be able to achieve this by calling the relevant pool function repeatedly as long as it returns a specific type of error (which might be different types of errors according to different needs). You can write a module for that.

I think library users should be able to achieve this by calling the relevant pool function repeatedly as long as it returns a specific type of error (which might be different types of errors according to different needs). You can write a module for that.

I understand your suggestion, but we are using an ORM (TypeORM) and it does not allow to trick that point easily (we have to change the driver to achieve what you suggest).
I believe it would be reasonable for the connection pool to handle retrying failed connections, within a configurable limit, for a predefined set of error types.
I agree that limiting the retries to only timeout errors is too specific/restrictive. I can improve that by exposing a function in the configuration options to check if an error should trigger the retries (like in TypeORM config: toRetry: (err) => boolean)

What do you think @charmander ? Can I re-open this PR and improve the behavior as explained?