On 5/20/15 5:21 PM, Robert Haas wrote:
> On Tue, May 19, 2015 at 5:02 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> That's a reasonable argument. So +1 to protocol from me.
>>
>> To satisfy Tom, I think this would need to have two modes: one where the
>> session can never be reset, for ultra security, and one where the session
>> can be reset, which allows security and speed of pooling.
>
> I think the the second one is a lot more interesting, but I don't have
> a problem with having the first one, too, if somebody wants it. We
> can use one protocol message for both, with a 1-byte character field
> used to indicate which mode the client is requesting.
Now that we're on the topic of interesting things, would it make sense
to add protocol support for a sort of a "re-authenticate"? So a pooler
could first say "this user wants to log in from this host", then get
back a message saying how to authenticate that user, which the pooler
could then pass that on to the client. Once the client has passed its
credentials, the pooler could (possibly in another backend) try to
authenticate using those credentials, and only then set the session's
authentication. This would allow for more transparent poolers while
still, well, pooling connections.
I haven't thought about this at all, so maybe it's a stupid idea (or the
backends don't have all the information to do this), or whatever.
.m