|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|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|