database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00
Code Activity

Allow psql to re-use connection parameters after a connection loss.

Browse Source 
Instead of immediately PQfinish'ing a dead connection, save it aside
so that we can still extract its parameters for \connect attempts.
(This works because PQconninfo doesn't care whether the PGconn is in
CONNECTION_BAD state.)  This allows developers to reconnect with
just \c after a database crash and restart.

It's tempting to use the same approach instead of closing the old
connection after a failed non-interactive \connect command.  However,
that would not be very safe: consider a script containing
	\c db1 user1 live_server
	\c db2 user2 dead_server
	\c db3
The script would be expecting to connect to db3 at dead_server, but
if we re-use parameters from the first connection then it might
successfully connect to db3 at live_server.  This'd defeat the goal
of not letting a script accidentally execute commands against the
wrong database.

Discussion: https://postgr.es/m/38464.1603394584@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2020-10-23 17:07:15 -04:00
parent 860593ec3b
commit 1b62d0fb3e
6 changed files with 73 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
doc/src/sgml/ref/psql-ref.sgml
View File

@@ -931,12 +931,23 @@ testdb=>
connection is closed.
If the connection attempt fails (wrong user name, access
denied, etc.), the previous connection will be kept if
<application>psql</application> is in interactive mode. But when
executing a non-interactive script, processing will
immediately stop with an error. This distinction was chosen as
<application>psql</application> is in interactive mode. But when
executing a non-interactive script, the old connection is closed
and an error is reported. That may or may not terminate the
script; if it does not, all database-accessing commands will fail
until another <literal>\connect</literal> command is successfully
executed. This distinction was chosen as
a user convenience against typos on the one hand, and a safety
mechanism that scripts are not accidentally acting on the
wrong database on the other hand.
Note that whenever a <literal>\connect</literal> command attempts
to re-use parameters, the values re-used are those of the last
successful connection, not of any failed attempts made subsequently.
However, in the case of a
non-interactive <literal>\connect</literal> failure, no parameters
are allowed to be re-used later, since the script would likely be
expecting the values from the failed <literal>\connect</literal>
to be re-used.
</para>
<para>