Tom Lane <t...@sss.pgh.pa.us> wrote: > Bruce Momjian <br...@momjian.us> writes: > >> I have fixed pg_upgrade in git-head with the attached patch, >> which prepends default_transaction_read_only=false to PGOPTIONS. > > What is the point of this, given that Kevin fixed pg_dumpall? > Don't those fixes take care of the issue? > > If your argument is that you want pg_upgrade to work even if the > user already turned on default_transaction_read_only in the *new* > cluster, I would humbly disagree with that goal, for pretty much > the same reasons I didn't want pg_dump overriding it.
If there were databases or users with default_transaction_read_only set in the old cluster, the pg_dumpall run will cause that property to be set in the new cluster, so what you are saying seems to be that a cluster can't be upgraded to a new major release if any database within it has that set. My personal feeling is that it would be good if that were not a barrier to using pg_upgrade; but it would be OK as long as running it with the --check option *tells* you that the cluster can't be upgraded without turning that property off for all databases, and that the user under which it runs can't have the property set. -- 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
