On Sat, Nov 30, 2013 at 06:48:02PM -0500, Tom Lane wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
> > Tom Lane <tgl@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +