diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2018-01-23 10:55:08 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2018-01-23 10:55:16 -0500 |
| commit | 160a4f62ee7b8a96984f8bef19c90488aa6c8045 (patch) | |
| tree | 94132d90908747df1f154ccf50d5263c8cb8d878 /src/bin/pg_dump/pg_dump.c | |
| parent | a541dbb6fa389bb0ffdd24a403bc6d276d77a074 (diff) | |
| download | postgresql-160a4f62ee7b8a96984f8bef19c90488aa6c8045.tar.gz postgresql-160a4f62ee7b8a96984f8bef19c90488aa6c8045.zip | |
In pg_dump, force reconnection after issuing ALTER DATABASE SET command(s).
The folly of not doing this was exposed by the buildfarm: in some cases,
the GUC settings applied through ALTER DATABASE SET may be essential to
interpreting the reloaded data correctly. Another argument why we can't
really get away with the scheme proposed in commit b3f840120 is that it
cannot work for parallel restore: even if the parent process manages to
hang onto the previous GUC state, worker processes would see the state
post-ALTER-DATABASE. (Perhaps we could have dodged that bullet by
delaying DATABASE PROPERTIES restoration to the end of the run, but
that does nothing for the data semantics problem.)
This leaves us with no solution for the default_transaction_read_only issue
that commit 4bd371f6f intended to work around, other than "you gotta remove
such settings before dumping/upgrading". However, in view of the fact that
parallel restore broke that hack years ago and no one has noticed, it's
fair to question how many people care. I'm unexcited about adding a large
dollop of new complexity to handle that corner case.
This would be a one-liner fix, except it turns out that ReconnectToServer
tries to optimize away "redundant" reconnections. While that may have been
valuable when coded, a quick survey of current callers shows that there are
no cases where that's actually useful, so just remove that check. While at
it, remove the function's useless return value.
Discussion: https://postgr.es/m/12453.1516655001@sss.pgh.pa.us
Diffstat (limited to 'src/bin/pg_dump/pg_dump.c')
| -rw-r--r-- | src/bin/pg_dump/pg_dump.c | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index 11e1ba04cc4..d65ea54a69b 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -2819,10 +2819,11 @@ dumpDatabase(Archive *fout) /* * Now construct a DATABASE PROPERTIES archive entry to restore any - * non-default database-level properties. We want to do this after - * reconnecting so that these properties won't apply during the restore - * session. In this way, restoring works even if there is, say, an ALTER - * DATABASE SET that turns on default_transaction_read_only. + * non-default database-level properties. (The reason this must be + * separate is that we cannot put any additional commands into the TOC + * entry that has CREATE DATABASE. pg_restore would execute such a group + * in an implicit transaction block, and the backend won't allow CREATE + * DATABASE in that context.) */ resetPQExpBuffer(creaQry); resetPQExpBuffer(delQry); @@ -2854,8 +2855,7 @@ dumpDatabase(Archive *fout) /* * We stick this binary-upgrade query into the DATABASE PROPERTIES archive - * entry, too. It can't go into the DATABASE entry because that would - * result in an implicit transaction block around the CREATE DATABASE. + * entry, too, for lack of a better place. */ if (dopt->binary_upgrade) { |