Bruce Momjian <br...@momjian.us> wrote: > On Wed, Nov 27, 2013 at 06:05:13AM -0800, Kevin Grittner wrote: >> Bruce Momjian <br...@momjian.us> wrote:
>>> I am confused what we are patching. Are we patching pg_dump, >>> pg_dumpall, or both? >> >> Just pg_dumpall.c. > > OK, there was a pg_dump patch earlier which we are not using now. Right, that was v1, early in the discussion. This is v3, based on responding to the discussion on this thread. > What is the logic that has us setting statement_timeout in > pg_dump but default_transaction_read_only in pg_dumpall? Of the people who posted on this thread supporting that, I think Tom said it best: 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. -- Kevin GrittnerEDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
