On 03/21/2017 08:02 AM, Haribabu Kommi wrote:
Solution -1) Just ignore dumping these CREATE DATABASE
commands and provide the user information in the documentation
to create "postgres" and "template1" database in the target in case
if they don't exist. If this kind of cases are very rare.
Solution-2) Add a new command line option/some other settings
to indicate the pg_dump execution is from pg_dumpall and follow
the current refactored behavior, otherwise follow the earlier pg_dump
behavior in handling CREATE DATABASE commands for "postgres"
and "template1" databases.
I am leaning towards (2) since I feel having pg_dump act differently
depending on the name of the database is a quite surprising behavior. It
makes more sense to let a tool like pg_dumpall handle logic like that.
2. In dumpDatabases function before calling the runPgDump command,
Before refactoring, it used to connect to the database and dump
"SET default_transaction_read_only = off;" to prevent some accidental
overwrite of the target.
I fixed it in the attached patch by removing the connection and dumping
the set command.
Does it needs the similar approach of solution-2) in previous problem and
handle dumping the "SET default_transaction_read_only = off;" whenever
the CREATE DATABASE and \connect command is issued?
Hm, that is a bit annoying. I do not think we want to change any
behavior here, either of pg_dump or pg_dumpall, but I also do not like
having to add two new flags to pg_dump (one for including the ALTER
DATABASE commands but not CREATE DATABASE, and another flag for
default_transaction_read_only) or a special flag similar to
--binary-upgrade.
None of these options seem optimal to me, and I do not have any strong
preference other than that we should avoid breaking pg_dump or changing
behavior not related to the database attributes.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
