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 the most part, before seems > > better, because it seems a bit silly to force people to authenticate just > > so that you can tell them to go someplace else. Also, that would lead to > > double authentication, which might for example result in multiple > > 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
