Re: Mop-up around psql's \connect behavior

At Thu, 22 Oct 2020 15:23:04 -0400, Tom Lane <tgl@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