This makes it much less likely a "stale" store connection that hasn't
actually been checked for liveness gets used. (Long story short, there
could be one more connection than RelStorage instance because of how
these were managed, and that connection would be rarely used, only
when the ZODB connection pool is overgrown. Closing or timing out ZODB
connections wouldn't actually remove that one.)
With psycopg2, restarting a store connection sometimes/often doesn't
have to actually communicate with the database if we know we're not in
a transaction. This could make a OperationalError pop up at an unusual
time.
This doesn't change that, but it does fix it so that resolving the
underlying issue doesn't leave a time bomb waiting.
This makes it much less likely a "stale" store connection that hasn't actually been checked for liveness gets used. (Long story short, there could be one more connection than RelStorage instance because of how these were managed, and that connection would be rarely used, only when the ZODB connection pool is overgrown. Closing or timing out ZODB connections wouldn't actually remove that one.)
With psycopg2, restarting a store connection sometimes/often doesn't have to actually communicate with the database if we know we're not in a transaction. This could make a OperationalError pop up at an unusual time.
This doesn't change that, but it does fix it so that resolving the underlying issue doesn't leave a time bomb waiting.
Gardening changes