bug(pg): Demonstrating (or trying to) bug with many crons.

[elliotcourant]

This demonstrates an issue where it is easily possible to have more jobs or job handlers than the connection pool will allow. In tests the max conns defaults to 2 but otherwise pgxconn defaults to runtime.NumCPU.

I'm running into an issue where I'm running several small containers with sometimes less than a single CPU core each (since I don't need much). But because of how the connection pool works this ends up causing deadlocks since the acquire function calls themselves do not have timeouts (since ctx is just cascaded throughout).

More details can be seen here about my specific use case: monetr/monetr#1608

---

I guess overall, does it make sense to have a connection pool that has an arbitrary hard limit on connections? Even if someone were to just configure a higher limit (or maybe a significantly higher limit); most of the connections will be consumed not by jobs themselves but by the listeners associated with those jobs? Which means that you must have at least N max conns for N jobs?

The other thing would be how ctx is cascaded throughout, if I call Start or StartCron I cannot pass a WithTimeout context because that will cause actual parts of the handler or listener to timeout (like listening for notifications which is async anyway) where I might want to specify "the setup of this job should only take 10 seconds"?
I think the approach with how timeouts should happen with async work happening in the background vs work that is synchronous initiated by a caller should be thought about as part of this as well.

[acaloiaro]

Opened #103 for this.

[acaloiaro]

Fixed by #103