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

At Thu, 22 Oct 2020 15:23:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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