On Sun, Nov 21, 2021 at 03:11:03AM +1100, Todd Hubers wrote:
> I have just joined to start a community consultation process for a
> proposal. I just finished the proposal document, I spent time writing a
> Problem and Solution section, and I have done quite a bit of upfront
> exploration of the code.
>
> - Google Document with Commenting turned on
> https://docs.google.com/document/d/1u6mVKEHfKtR80UrMLNYrp5D6cCSW1_arcTaZ9HcAKlw/edit?usp=sharing.
The stated goal is to support persistent connections with hundreds or thousands
of different users.
However, this doesn't attempt to address the similar issue if there's hundreds
or thousands of DBs. Which I don't think could work at all, since switching to
a new DB requires connecting to a new backend process.
You proposed a PQ protocol version of SET ROLE/SET SESSION authorization.
You'd need to make sure that a client connected to the connection pooler cannot
itself run the PQ "set role". The connection pooler would need to reject the
request (or maybe ignore requests to switch to the same/current user). Maybe
you'd have two protocol requests "begin switch user" and "end switch to user",
and then the server-side could enforce that "begin switch" is not nested.
Maybe the "begin switch" could return some kind of "nonce" to the connection
pooler, and "end switch" would require the same nonce to be validated.
It'd be interesting to hear if you've tested with postgresql 14, which improves
scalability to larger number of connections.
--
Justin