Postgres Pro
Downloads
Home   >   mailing lists

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall
Date
Msg-id CAJrrPGfWbMHBxnkAEUHqWbo7OsyYb3zjo8J73VF1s+gy2_YQAQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: [HACKERS] Refactor handling of database attributes betweenpg_dump and pg_dumpall  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
Tree view

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
Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4
Next
From: Jeevan Chalke
Date:
Subject: [HACKERS] Partition-wise aggregation/grouping