Re: [GENERAL] pg_upgrade ?deficiency

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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-25 22:24:25
Message-ID: 1385418265.31558.YahooMailNeo@web162902.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Kevin Grittner wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>>> I am not a fan of backpatching any of this.
>>
>> Here's my problem with that.  Here's setup to create what I
>> don't think is all that weird a setup:
>>
>> The cluster is created in the state that was dumped, default
>> read only flags and all.
>>
>> Are you saying that you find current behavior acceptable in back
>> branches?
>
> First, I don't need to see a 300-line pg_dump restore output to
> know it is a bug.

I was trying to save people the trouble of working up their own
test to see what happened when running pg_dumpall output from a
successful run into a freshly initdb'd cluster.  No offense
intended.

> Second, what you didn't do is to address the rest of my
> paragraph:
>
>> I am not a fan of backpatching any of this.  We have learned the
>> fix is more complex than thought,

I didn't realize that anyone thought the pg_dumpall fix would
amount to something simpler than two printf statements; but even
so, that seems pretty reasonable to me.

>> and the risk of breakage and having pg_dump diffs change between
>> minor releases doesn't seem justified.

You might have missed the part of the thread where we seemed to
have reached a consensus that pg_dump output would not change at
all; only pg_dumpall output -- to something capable of being
restored to a fresh cluster.

> We have to balance the _one_ user failure report we have received
> vs. potential breakage.

What breakage mode do you see?

> Now, others seem to be fine with a backpatch, so perhaps it is
> safe.  I am merely pointing out that, with all backpatching, we
> have to balance the fix against possible breakage and behavioral
> change.

Sure, but I think a bug in a dump utility which allows it to run
with apparent success while generating results which don't restore
is pretty clearly something to fix.  FWIW I don't feel as strongly
about the pg_upgrade aspect of this -- as long as a test run
reports that the cluster can't be upgraded without changing those
settings, there is no problem.  Of course it would be nice if it
could be fixed instead, but that's not as critical in my view.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2013-11-25 23:58:52 Re: [GENERAL] pg_upgrade ?deficiency
Previous Message Scott Marlowe 2013-11-25 22:06:38 Re: wiki on monitoring locks has queries that don't seem to work

Browse pgsql-hackers by date

  From Date Subject
Next Message Piotr Marcinczyk 2013-11-25 22:28:11 Re: Add \i option to bring in the specified file as a quoted literal
Previous Message Heikki Linnakangas 2013-11-25 22:23:48 Re: PL/Python: domain over array support