Hi,
Ran into a cast-to-text error when trying to connect to a postgres 8.2
database with rails 4.2.4. I noticed the fix is already in master (
https://github.com/rails/rails/commit/8c34d106ca66a03a78739c411a2f4ecb9fcad25d),
but was wondering if this could get backported to the next minor ver
On Thu, Oct 1, 2015 at 4:25 AM, Xavier Noria wrote:
> The only time I've seen one connection per thread being an issue was in
> one app that ran many processes and it started to reach the connection
> limit of their db server in traffic peaks. Even in that scenario,
> contention is also a risk if
Agreed.
The biggest benefit is going to come to people using a DB like Postgres
where each connection uses an entire backend (forked worker essentially),
and, given the high cost of backends, it's recommended to keep the number
of connections low.
Checking connections in/out of the pool as necess
We run into problems with connection pools on Heroku.
In Postgres a connection is very expensive. The cheap/free plans on Heroku
Postgres all have very small connection limits. The hobby plan is limited to 20
connections https://devcenter.heroku.com/articles/heroku-postgres-plans.
Some pe
If the concern is long-running threads holding DB connections they don't
need, wouldn't a simpler solution be to explicitly return connections to
the pool (via release_connection) before doing a long-running non-DB
operation? Checking out and back in on most operations seems like
optimizing for tha
The only time I've seen one connection per thread being an issue was in one
app that ran many processes and it started to reach the connection limit of
their db server in traffic peaks. Even in that scenario, contention is also
a risk if you reduce the pool.
Other than the mental image that you're
