On Sun, Dec 1, 2013 at 09:22:52AM +0100, Karsten Hilbert wrote: > On Sat, Nov 30, 2013 at 03:21:08PM -0800, Kevin Grittner wrote: > > > > 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. > > That is *precisely* my use case which I initially asked about.
The use-case would be that default_transaction_read_only is turned on in postgresql.conf as part of installing the old and/or new cluster. The 9.4 PGOPTIONS fix for pg_upgrade _will_ allow such a cluster to be upgraded. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
