On Sat, Nov 30, 2013 at 06:48:02PM -0500, Tom Lane wrote: > Kevin Grittner <kgri...@ymail.com> writes: > > Tom Lane <t...@sss.pgh.pa.us> wrote: > >> What is the point of this, given that Kevin fixed pg_dumpall? > >> Don't those fixes take care of the issue? > > > 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. > > Oh, I had forgotten that pg_upgrade will run additional commands > against the new cluster after restoring the dumpall output.
Actually, pg_upgrade used to use pg_dumpall but since PG 9.3 is used pg_dumpall --globals-only and pg_dump on each database, which allows parallel operations. Also, there are other libpq sessions that modify the new cluster, so PGOPTIONS is the best option. I was happy the patch was so small. -- 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
