On Mon, Feb 12, 2018 at 1:56 PM, Satyanarayana Narlapuram <satyanarayana.narlapu...@microsoft.com> wrote: > I simplified the patch and for now just allowed one server. Please find the > attached patches, and the commit message.
This patch -- -- doesn't include nearly sufficient documentation updates. For example, the new message type is not documented in the list of message types. The documentation of which messages are legal in which contexts is not updated to mention this new message. The new ConnStatusType is not documented (and is it really needed?). The documentation for the new pg_hba.conf parameter does not explain how to specify the alternate server to which you wish to connect. -- includes no tests. -- does include irrelevant whitespace differences. -- doesn't include any provision for clients to fall back to 3.0 if 3.1 is not supported. -- doesn't seem to have proper provisions for the server to handle older clients. The code looks like just skips over hba.conf redirect lines if the client is older, which seems like not what we want. The proposed commit message claims we just go ahead and send redirects to older clients that aren't expecting them, which is pretty much missing the entire point of having minor protocol versions. I think the right way to handle this case is to throw FATAL with the error text suggesting the host/port to which the user should try connecting. -- probably needs defenses against infinite redirect loops. Most likely we should see how this is normally handled by HTTP clients and do something similar here. -- probably needs some way for clients to express unwillingness to follow redirects. Possibly that could be combined with the previous item by having a new connection parameter indicating the number of redirects the client is willing to follow, with the default being, say, 10 (browsers apparently have a limit of 10 or 20 for HTTP, but 20 seems overly generous for a database connection) and 0 disabling. -- might need some defense against the redirected-to server getting the same password as was sent to the original server. Is that a security risk? Does HTTP have a rule about this? -- might need some way for clients to discover whether they got redirected and, if so, the server to which they were redirected. For example, if I connect with psql, get redirected, and then type \conninfo, do I get the information on the server to which I think I connected, or the server to which I got redirected? Maybe we should display both? If the connection gets retried, do we retry the original server or the server to which we were redirected? I'd argue for the former, but maybe other people think differently. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company