Re: [HACKERS] Client Connection redirection support for PostgreSQL

On 05/03/18 22:18, Satyanarayana Narlapuram wrote:
> Please see the attached patch with the comments.
> 
> Changes in the patch:
>     A client-side PGREDIRECTLIMIT parameter has been introduced to control the maximum number of retries.
>     BE_v3.1 sends a ProtocolNegotiation message. FE_v3.1 downgrades to v3.0 upon receipt of this message.
>     FE falls back to v3.0 if 3.1 is not supported by the server.
> 
> 
>     >> I hadn't really thought deeply about whether redirection should happen before or after authentication.  For
themost part, before seems better, because it seems a bit silly to force people to authenticate just so that you can
tellthem to go someplace else.  Also, that would lead to double authentication,          which might for example result
inmultiple password prompts, which users might either dislike or find confusing.
 
> 
>     Yes, redirection before authentication would avoid multiple password prompts.

I think we should have this feature. I can see a redirect being useful 
in some similar cases like HTTP redirects are useful, but a database 
server is not a web server. There are no redirects in IMAP or most other 
protocols, either.

This would also require modifying every client library to honor the 
redirect.

How would the redirect behave with TLS certificate verification? If you 
are redirected from "foo-server" to "bar-server", but the original 
connection string was "host=foo-server sslmode=verify-full", would the 
connection be allowed?

FWIW, if we were to do this, I think pg_hba.conf would be a fine place 
for this. That's where you currently have configuration for what happens 
when a client with certain host/username/database tries to connect. In 
addition to "accept" or "reject", it seems logical to add "redirect" as 
an outcome, instead of e.g. adding a whole new configuration file fore this.

But overall, IMHO we should mark this patch "rejected".

- Heikki