Re: [GENERAL] pg_upgrade ?deficiency - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [GENERAL] pg_upgrade ?deficiency
Date
Msg-id 20131202164110.GC5274@momjian.us
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade ?deficiency  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Responses Re: [GENERAL] pg_upgrade ?deficiency
List pgsql-hackers
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  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Next
From: Bruce Momjian
Date:
Subject: Re: DATE type output does not follow datestyle parameter