Live data from Hacker News

Odyssey – Scalable PostgreSQL connection pooler

github.com

41–42 of 42 posts

Re: Odyssey – Scalable PostgreSQL connection pooler

#41
post #40

Earlier quoted context omitted.

Uh oh. I naturally assumed Rails runs every request in a transaction because that's obviously the default you want.

Not really. Though this should be trivial to do - just start and commit in the base controller life cycle hooks - I would never want or recommend it as he default. Too many things can go wrong with out of hand work, sequencing, assuming that hooks will happen when you do call save methods etc.

Why would you not have that as a default? What things can go wrong? Not having it means you have to think about transactions in every method or you accept database inconsistency.

Re: Odyssey – Scalable PostgreSQL connection pooler

#42
post #9

This looks pretty interesting. Will definitely spend some time testing it. Shameless plug. We have recently forked pgbouncer to add multicore support[0]. We are running in production for couple of weeks and the performance is great. Our design is very straightforward. Instead of touching the current code, we've extended it by a manager, that spins workers, which are essentially forks of pgbouncer itself (one per core…

We've solved this problem by running 4 instances of pgbouncer and placing them behind a load balancer.
Post reply on HN