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

From Kevin Grittner
Subject Re: [GENERAL] pg_upgrade ?deficiency
Date
Msg-id 1385418265.31558.YahooMailNeo@web162902.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: [GENERAL] pg_upgrade ?deficiency  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [GENERAL] pg_upgrade ?deficiency  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> wrote:
> Kevin Grittner wrote:
>> Bruce Momjian <bruce@momjian.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



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: PL/Python: domain over array support
Next
From: Piotr Marcinczyk
Date:
Subject: Re: Add \i option to bring in the specified file as a quoted literal