Re: [GENERAL] pg_upgrade ?deficiency

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 23:46:01
Message-ID: 20131128234601.GC11652@hermes.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, Nov 28, 2013 at 10:39:18AM -0500, Bruce Momjian wrote:

> Well, then we are actually using two different reasons for patching
> pg_dumpall and not pg_dump. Your reason is based on the probability of
> failure, while Tom/Kevin's reason is that default_transaction_read_only
> might be used to block changes to a specific database, and they want a
> pg_dump restore prevented, but a pg_dumpall restore to succeed.

I can't really argue one way or another because *I* am
not likely to be able to offer an actual patch. At any
rate all I am interested in is that pg_upgrade does not
fail to upgrade in surprising ways.

Regarding restoring a pg_dump IMO the line would need to
be drawn along the -c/--clean option because using such seems
to clearly say that, yes, the user *wants* data to be deleted.

If -C/--create is used it shouldn't matter ...

However, I'm not saying that this is how it is to
be done. I am well aware that drawing such subtle
distinctions is walking quite a fine line.

Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Randy Burkhardt 2013-11-28 23:52:11 Unable to write inside TEMP environment path
Previous Message Tobadao 2013-11-28 21:17:09 Error pg_standby 'pg_standby' is not recognized as an internal or external command!!

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Karlsson 2013-11-29 00:13:11 Todo item: Support amgettuple() in GIN
Previous Message Bruce Momjian 2013-11-28 22:38:05 Re: 9.2.1 & index-only scans : abnormal heap fetches after VACUUM FULL