It's awesome to see AGPL instead of the horrible BSL variants that have been going around.
It is quite telling that most cloud companies stay away from AGPL. Their business model is antisocial.
You mean the licence is anti-business and pro-social.
Why we built yet another Postgres connection pooler
51–60 of 74 posts
Re: Why we built yet another Postgres connection pooler
#52[flagged]
Re: Why we built yet another Postgres connection pooler
#53Doesn't this NOTIFY performance fix mean that it isn't transactional any more?
From the strictest CAP theorem definition, that's correct, it is not. But, it's pretty close. I know that in the database world, that's not a good answer, but in practice, it will deliver the vast majority of messages, so maybe that's good enough? We'll see. We show that it's possible to come close without breaking the DB or the app, but I suspect, it's not quite yet at the level you'd expect from a _durable_ work qu…
Please document this, if that's not the case already.
Thank you for open sourcing this!
Re: Why we built yet another Postgres connection pooler
#54Postgres features still "just work" behind the pooler.
Re: Why we built yet another Postgres connection pooler
#55[flagged]
Re: Why we built yet another Postgres connection pooler
#56Earlier quoted context omitted.
It's not unique to postgres, as others have said; the same thing can happen with e.g. MySQL poolers/proxies/etc., since the behavior of the connection can be changed dynamically and it persists for the lifetime of the connection. Example: legacy client A connects to MySQL via the bouncer and says 'I want all of our conversations to use latin-1, not utf-8'. This changes the character set that MySQL parses queries with…
Recently ran into a related bug in duckdb. They implemented a basic http connection pooler (described as a parking lot) but there are edge cases where broken connections get returned to the pool then the next thing tries to use a busted connection and fails.
DuckDB is in-process though?
Re: Why we built yet another Postgres connection pooler
#57Earlier quoted context omitted.
Recently ran into a related bug in duckdb. They implemented a basic http connection pooler (described as a parking lot) but there are edge cases where broken connections get returned to the pool then the next thing tries to use a busted connection and fails.
DuckDB is in-process though?
Yeah, just another example of "connections pools are hard in general"
Re: Why we built yet another Postgres connection pooler
#58Earlier quoted context omitted.
>might bringt Postgres finally closer to vitess Supabase are launching a Vitess for Postgresql, they have hired the original creator of Vitess for it https://supabase.com/blog/multigres-vitess-for-postgres
And Planetscale (who is the current primary maintainer of vitess) is developing a Vitess for PostgreSQL. There will be a couple of production-grade PG vitess solutions the next months.
Famous last words.
There will be 0 production grade solutions in the next months, I guarantee it
Re: Why we built yet another Postgres connection pooler
#59And why it should be done upstream with a thread pool model and an internal scheduler as MS SQL server does.
Re: Why we built yet another Postgres connection pooler
#60[dead]