At Thu, 22 Oct 2020 15:23:04 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in > I wrote: > > 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. > > Actually ... I'd no sooner pushed that patch than I realized that there > *is* an easy, if rather grotty, way to deal with this. We can just not > issue PQfinish on the old/dead connection until we've successfully made > a new one. PQconninfo doesn't care if the connection is in BAD state. > > To avoid introducing weird behaviors, we can't keep the logically-dead > connection in pset.db, but introducing a separate variable to hold such > a connection doesn't seem too awful. So that leads me to the attached > patch, which is able to reconnect even if we lost the connection:
Sounds reasonable. > regression=# select 1; > ?column? > ---------- > 1 > (1 row) > > -- in another window, stop the server, then: > > regression=# select 1; > FATAL: terminating connection due to administrator command > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > > --- now restart the server, and: > > !?> \c > You are now connected to database "regression" as user "postgres" via socket > in "/tmp" at port "5432". Looks good to me. I'm very happy with the result. > I would not have wanted to accept a patch that did it the other way, > because it would have been a mess, but this seems small enough to > be worth doing. The only real objection I can see is that it could > hold a server connection open when the user thinks there is none; > but that could only happen in a non-interactive script, and it does > not seem like a big problem in that case. We could alternatively > not stash the "dead" connection after a non-interactive \connect > failure, but I doubt that's better. Agreed. Thanks! regards. -- Kyotaro Horiguchi NTT Open Source Software Center
