The $subject commit broke internal_schema_cache_sleep for other tests.
This reverts the order change, but keeps the scaling by x1000 to ms and
thus changes other users of this setting to the new scale.
By increasing the delays in this test by factor 400x, postgrest will not
swamp pg with connection retries after the failed schema cache anymore.
This would happen because there is no backoff included after fatal
errors. Once it does, the io tests hang indefinitely in CI.
The statement timeout needs to be cleaned up after each test that
modifies it instead of before the test. Otherwise the changed timeout
leaks into other tests.
This required untangling logic from App.hs.
Building/rejecting a plan no longer consumes a pool connection.
* Added io test for failed resource embedding not consuming connection
* optionalrollback to Query.hs and Response.hs
* delete Middleware module
* remove plan logic from App.hs
* remove RequestContext
* remove pkCols logic from App.hs
* remove proc logic from App.hs
* remove config logic from handleRequest
The configuration option db-pool-acquisition-timeout
specifies the time in seconds to wait for the pool to
free up a connection slot. Otherwise, a 504 error is
returned. By default, there is no timeout.
This version of hasql-pool is a simplified rewrite that doesn't use
the resource-pool package. The major API changes are that idle
connections are no longer timed out (and the corresponding setting
is gone), and that `release` makes the pool unusable, where it used
to remain usable and only flushed idle connections.
We depend on a PostgREST fork of 0.7.2 that gives us reliable
flushing, compare https://github.com/PostgREST/hasql-pool/pull/1
- hasql-pool 0.7 removes timing out of idle connections, so
this change removes the db-pool-timeout option.
Given that we were typically running with very high
timeout settings, I don't anticipate the lack of timeout
to introduce new issues, though we might want to consider
introducing some retry-logic down the line when we
encounter connection failures.
- See https://github.com/PostgREST/postgrest/issues/2422 for a
discussion on depending on a forked dependency. Besides adding
the dependency to the nix overlay, we're also adding it to
stack.yaml and a new cabal.project to allow stack/cabal users
to build the project.
steve-chavez