Bruce Momjian <bruce@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
