Re: Feature Proposal: Connection Pool Optimization - Change the Connection User

> On 21 Nov 2021, at 03:05, Todd Hubers <todd(dot)hubers(at)gmail(dot)com> wrote:

> 10) Tom said: "How would this interact with the "on login" triggers that people keep asking for?
>
> That's a good point. I would imagine that SET ROLE (which is currently unsuitable) would have the same requirement. The answer is Shared Functions. SET ROLE calls a function like "SetSessionUserId". Our implementation should call the same function(s). If OnLogin functionality is implemented they should trigger from there.

I think thats conflating session_user and current_user, SET ROLE is not a login
event. This is by design and discussed in the documentation:

"SET ROLE does not process session variables as specified by the role's
ALTER ROLE settings; this only happens during login."

The current patch proposal doesn't fire the login event trigger on SET ROLE,
only on actual logins. That patch needs more review before landing, but I'm
not sure tying it to SET ROLE is a good idea.

> 13. Tom said: "I wonder how we test such a feature meaningfully without incorporating a pooler right into the Postgres tree."
>
> We can benchmark without a pooler - see the Benchmark section for details. (Furthermore, I propose that general benchmark tooling does belong in Postgres for the benefit of the ecosystem of connection poolers. I have included such a remark in the Benchmarking section "PostgreSQL is not planning to incorporate Connection Pooling...".)

We might be talking about the same things using different words, but it's
important to remember that we need to cover the functionality in terms of
*tests* first, performance benchmarking is another concern.

--
Daniel Gustafsson https://vmware.com/