Re: Refactor handling of database attributes between pg_dump and pg_dumpall

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Refactor handling of database attributes between pg_dump and pg_dumpall
Date: 2017-03-23 10:45:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

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.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2017-03-23 10:56:05 Re: segfault in hot standby for hash indexes
Previous Message Dave Page 2017-03-23 10:41:47 Re: Monitoring roles patch