This PR adds a fix to not throw the "failed to allocate cancel handle" error.
We can't get a cancel handle when the connection has become invalid [1].
How can a connection suddenly become invalid? A connection is established
when new connections are added to the pool. But the cancel handle is
setup when the connection is acquired through the pool, which may be much
later than when the connection is actually setup. So it may be e.g.
several minutes or hours old already. So we don't setup the cancellation,
because the query is going to fail anyway on this invalid connection. If
we throw an error here, it becomes confusing for the user. An appropriate
way to handle it would be to throw an invalid connection error here. But
we don't have any details on why the connection is invalid. If we let
postgres throw the error, it will have the actual error message/reason
for the invalid connection. Hence, it makes sense to not setup the
cancellation here and try to run the query, which will fail with proper
error message from Postgres. [1]:
https://hackage.haskell.org/package/postgresql-libpq-0.9.4.3/docs/Database-PostgreSQL-LibPQ.html#v:getCancel
Fixes #63
This PR adds a fix to not throw the "failed to allocate cancel handle" error.
We can't get a cancel handle when the connection has become invalid [1]. How can a connection suddenly become invalid? A connection is established when new connections are added to the pool. But the cancel handle is setup when the connection is acquired through the pool, which may be much later than when the connection is actually setup. So it may be e.g. several minutes or hours old already. So we don't setup the cancellation, because the query is going to fail anyway on this invalid connection. If we throw an error here, it becomes confusing for the user. An appropriate way to handle it would be to throw an invalid connection error here. But we don't have any details on why the connection is invalid. If we let postgres throw the error, it will have the actual error message/reason for the invalid connection. Hence, it makes sense to not setup the cancellation here and try to run the query, which will fail with proper error message from Postgres. [1]: https://hackage.haskell.org/package/postgresql-libpq-0.9.4.3/docs/Database-PostgreSQL-LibPQ.html#v:getCancel