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
