Re: [GENERAL] pg_upgrade ?deficiency

On Sat, Nov 30, 2013 at 06:48:02PM -0500, Tom Lane wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +