aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-10-23 17:07:15 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-10-23 17:07:15 -0400
commit1b62d0fb3e50ede570d0d4e4a2be69d5645b48a7 (patch)
tree014d70e9185c5d1f3994431f3352ea5cae0fda39 /src/backend/executor/nodeModifyTable.c
parent860593ec3bd15e8969effdfcb5cbd98c561dd722 (diff)
downloadpostgresql-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 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions