Re: [GENERAL] pg_upgrade ?deficiency

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. +