Because of this refactor handing of database objects between pg_dump and pg_dumpall, the latest pg_dump tap tests are failing in the following scenarios.
1. CREATE DATABASE postgres Before this patch, the pg_dump uses to dump the CREATE DATABASE command of postgres but not by pg_dumpall. During this refactor handling, the approach that I took in pg_dump for the --create option to use the similar appraoch of pg_dumpall to not to print the CREATE DATABASE commands for "postgres" and "template1" databases. It just prints the ALTER DATABASE commands to SET the TABLESPACE for those two databases. 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. 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? Documentation is yet to update to reflect the above changes. Regards, Hari Babu Fujitsu Australia
pg_dump_changes_3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
