On 2018-07-13 23:00:04 +0300, Heikki Linnakangas wrote:
> 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.
FWIW, I think it's quite dangerous to do the redirect before
authentication, and more importantly, certificate validation / channel
binding.
> 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.
I'd personally argue that it'd also make sense to have this as actual
database level option.
One thing where I can see a feature like this being quite helpful is
planned failovers, reducing the time to reconnect (for existing
connections) and rediscover (for new connections, which need to
write). But that'd require that the redirect needs to be able to be sent
in an established connection too.
Greetings,
Andres Freund
