At Thu, 22 Oct 2020 00:34:20 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in > Kyotaro Horiguchi <horikyota....@gmail.com> writes: > > At Wed, 21 Oct 2020 18:59:04 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in > > But once it got on my mind, it might be strange that just \c or \c > > -reuse-previous=y doesn't reconnect a broken session. It might be > > better we reuse the previous connection parameter even if the > > connection has been lost, but this would be another issue. > > I did actually look into saving the active connection's PQconninfo > immediately at connection establishment and then referring to it in any > subsequent \connect. Then things could work the same even if the original > connection had failed meanwhile. But there are technical details that > make that a lot harder than it seems on the surface --- mainly, that the > way do_connect works now requires that it have a copy of the PQconninfo > data that it can scribble on, and that won't do if we need the saved > PQconninfo to persist when a \connect attempt fails. That could be dealt > with with enough new code, but I didn't think it was worth the trouble.
Agreed. > (Note that we developers face the server-crashed scenario a whole lot more > often than normal people ;-), so we probably overrate how useful it'd be > to be able to reconnect in that case.) Agreed^2. > >> * The old-style-syntax code path understands that it should re-use > >> the old password (if any) when the user, host, and port settings > >> haven't changed. The connstring code path was too lazy to make > >> that work, but now that we're deconstructing the connstring there's > >> very little excuse for not having it act the same way. > > > +1 (I thought sslmode might affect but that is wrong since cert > > authenticaion cannot be turned off from command line.) > > Yeah. That could affect whether the server asks for a password at > all, but you have to really stretch to think of cases where it could > result in needing a *different* password. An example perhaps is > where pg_hba.conf is configured to do, say, LDAP auth on SSL connections > and normal password auth on non-SSL, and the LDAP server has a different > password than what is in pg_authid. But that seems like something nobody > could want. Also notice that unlike the previous code, with my patch > do_connect will always (barring --no-password) give you an opportunity > to interactively supply a password, even if we initially reused an > old password and it didn't work. So it seems like this will cope > even if you do have a setup as wacko as that. I thought of that scenarios and conclused as the same. Sounds reasonable. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
