On 05/19/2015 09:00 PM, Simon Riggs wrote:
[snip]
I think the idea of having SET SESSION AUTH pass a cookie, and
only let
RESET SESSION AUTH work when the same cookie is supplied, is pretty
reasonable.
As long as the cookie is randomly generated for each use, then I don't
see a practical problem with that approach.
Protocol level solution means we have to wait 1.5 years before anybody
can begin using that. I'm also dubious that a small hole in the
protocol arrangements could slam that door shut because we couldn't
easily backpatch.
Having an in-core pooler would be just wonderful because then we could
more easily trust it and we wouldn't need to worry.
Ufff.... Please don't do that.
Postgres is "just" a database. And a very good one at that. Let us keep
it that way and not try to re-implement everything within it --- We're
not "the big red company" after all :)
There are places where a pooler is badly needed.... and others where it
is just overkill and counterproductive.
Plus, scalability models / usage patterns are not nearly the same (nor
even compatible sometimes!) between databases and poolers.
There exist perfectly good solutions already (and they can certainly be
improved), such as PgBouncer (or even PgPool-II) or others can be adopted.
Just my .02€
/ J.L.
