Bruce Momjian <br...@momjian.us> wrote: > How are we handling breakage of pg_dump, not pg_dumpall?
That was discussed. Do you have something to add? > doc patch? Instead of the fix you mean, or with it? I don't see what we would change in the docs for the fix; the alternative might be to document that pg_dumpall output will fail to restore if any database (or the restoring user) has this property set. > pg_upgrade probably needs a doc patch too, or a reset like > pg_dumpall. pg_upgrade is more like pg_dumpall, so a code patch > seems most logical, again, assuming we decide that pg_dumpall is > the right place for this reset of default_transaction_read_only. I don't have much opinion on what the pg_upgrade aspect except, like I said, that if it is going to fail, it should fail in the check. Passing the check but failing during the upgrade would not be very user-friendly. Again, I'm not sure that a doc patch is needed to say that pg_upgrade works even when this option is set. Why would anyone assume otherwise? Why would we list this property and not others? I'm willing to do the pg_dumpall patch but would rather not take on pg_upgrade. If you would rather I leave the whole thing to you, that's OK, too. -- Kevin Grittner EDB: 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