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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: