On Wed, Nov 27, 2013 at 03:36:12PM -0800, Kevin Grittner wrote: > Tom Lane <t...@sss.pgh.pa.us> wrote: > > > I'm inclined to agree with Kevin that this behavior is wrong and > > should be fixed (and back-patched), so far as pg_dumpall is concerned. > > pg_dumpall's charter is to be able to recreate a database cluster's > > contents in a virgin installation, but it's failing to honor that > > contract if the cluster has any ALTER DATABASE SET default_read_only > > settings. Similarly, I think it's reasonable to try to make pg_upgrade > > cope with the case. > > > > I also agree with *not* changing pg_dump, since it is not the charter > > of pg_dump to recreate a whole cluster, and the objection about possibly > > restoring into a database that was meant to be protected by this setting > > seems to have some force. > > For example, I have seen dumps accidentally restored to the > postgres database on multiple occasions. You might, for example, > flag the postgres database with this, and thereby block such > accidents. The patch as it stands would allow pg_dumpall to > replicate such a cluster, flag and all. Without the patch you get > many errors. > > It is also much easier to work around with pg_dump output. You > could get a psql connection to a database, set this off for the > connection, and use \i to read the pg_dump output file. Or you > could concatenate a SET statement in front of the pg_dump output > when piping it in. There is no correspondingly easy solution for > pg_dumpall.
OK, I have read through this again, and now I see the idea is that we are trying to have pg_dumpall override the default_transaction_read_only value, but keep it for pg_dump restores. That is a pretty tricky use-case, so I think we need to mention this in the C comments. Tom and you think we should backpatch, and it seems only I am against it, so I suppose you can move forward. We are packaging soon for a minor release. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers