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
