diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-10-23 17:07:15 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-10-23 17:07:15 -0400 |
| commit | 1b62d0fb3e50ede570d0d4e4a2be69d5645b48a7 (patch) | |
| tree | 014d70e9185c5d1f3994431f3352ea5cae0fda39 /doc/src | |
| parent | 860593ec3bd15e8969effdfcb5cbd98c561dd722 (diff) | |
| download | postgresql-1b62d0fb3e50ede570d0d4e4a2be69d5645b48a7.tar.gz postgresql-1b62d0fb3e50ede570d0d4e4a2be69d5645b48a7.zip | |
Allow psql to re-use connection parameters after a connection loss.
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
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/ref/psql-ref.sgml | 17 |
1 files changed, 14 insertions, 3 deletions
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index f6f77dbac3a..221a967bfe6 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -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> |