From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>, "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-11-28 02:27:06 |
Message-ID: | 20131128022706.GG3785@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, Nov 27, 2013 at 03:36:12PM -0800, Kevin Grittner wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > I'm inclined to agree with Kevin that this behavior is wrong and
> > should be fixed (and back-patched), so far as pg_dumpall is concerned.
> > pg_dumpall's charter is to be able to recreate a database cluster's
> > contents in a virgin installation, but it's failing to honor that
> > contract if the cluster has any ALTER DATABASE SET default_read_only
> > settings. Similarly, I think it's reasonable to try to make pg_upgrade
> > cope with the case.
> >
> > I also agree with *not* changing pg_dump, since it is not the charter
> > of pg_dump to recreate a whole cluster, and the objection about possibly
> > restoring into a database that was meant to be protected by this setting
> > seems to have some force.
>
> For example, I have seen dumps accidentally restored to the
> postgres database on multiple occasions. You might, for example,
> flag the postgres database with this, and thereby block such
> accidents. The patch as it stands would allow pg_dumpall to
> replicate such a cluster, flag and all. Without the patch you get
> many errors.
>
> It is also much easier to work around with pg_dump output. You
> could get a psql connection to a database, set this off for the
> connection, and use \i to read the pg_dump output file. Or you
> could concatenate a SET statement in front of the pg_dump output
> when piping it in. There is no correspondingly easy solution for
> pg_dumpall.
OK, I have read through this again, and now I see the idea is that we
are trying to have pg_dumpall override the default_transaction_read_only
value, but keep it for pg_dump restores. That is a pretty tricky
use-case, so I think we need to mention this in the C comments.
Tom and you think we should backpatch, and it seems only I am against
it, so I suppose you can move forward. We are packaging soon for a minor
release.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Albert Chern | 2013-11-28 02:49:50 | Prefix search on all hstore values |
Previous Message | Bruce Momjian | 2013-11-28 02:22:50 | Re: [GENERAL] pg_upgrade ?deficiency |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-11-28 02:54:48 | Re: Put json type into alphabetical order in manual table |
Previous Message | Bruce Momjian | 2013-11-28 02:22:50 | Re: [GENERAL] pg_upgrade ?deficiency |