From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, "Hilbert, Sebastian" <Sebastian(dot)Hilbert(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] pg_upgrade ?deficiency |
Date: | 2013-12-01 08:22:52 |
Message-ID: | 20131201082252.GA5513@hermes.hilbert.loc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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.
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
From | Date | Subject | |
---|---|---|---|
Next Message | Tjibbe | 2013-12-01 11:39:04 | Re: Fwd: row_to_json() with numerical indices in stead of associative indices |
Previous Message | Michael Paquier | 2013-12-01 05:43:54 | Re: Fwd: row_to_json() with numerical indices in stead of associative indices |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-12-01 12:33:42 | Re: Incomplete freezing when truncating a relation during vacuum |
Previous Message | mohsen soodkhah mohammadi | 2013-12-01 07:59:57 | name.c |