pg_upgrade pain; was Re: Why is time with timezone 12 bytes?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_upgrade pain; was Re: Why is time with timezone 12 bytes?
Date: 2010-09-23 19:20:15
Message-ID: 201009231920.o8NJKFg09586@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas wrote:
> On Thu, Sep 23, 2010 at 1:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >>> Josh Berkus wrote:
> >>>> It would be a good project to add to the list of "easy TODOs to get
> >>>> started with."
> >
> >>> Except for the pg_upgrade issue.
> >
> >> Which is a big "except".
> >
> > Yeah. ?That constraint is what leads me to think that the return on
> > effort is just not worth it. ?Maybe we should file this in the category
> > of "things to look at next time we break on-disk compatibility".
>
> I'm worried about how we're going to manage that. First, as
> pg_upgrade becomes more mature, the penalty for breaking on-disk
> compatibility gets a LOT bigger. I'd like to think that "the next
> time we break on-disk compatibility" means approximately "never", or
> at least "not for a very long time". Second, if we do decide to break
> it, how and when will we make that decision? Are we just going to
> decide to break it when we run into a feature that we really want that
> can't be had any other way? If we want to make breaking on-disk
> compatibility something that only happens every 5 years or so, we had
> better give people - I don't know, a year's notice - so that we can
> really knock out everything people have any interest in fixing in one
> release.

Let me come clean and explain that I am worried pg_upgrade has limited
our ability to make data format changes.

pg_upgrade is much more accepted now than I think anyone expected a year
ago. Our users are now going to complain if pg_upgrade upgrades are not
supported in future releases, which eventually is going to cause us
problems.

I think having binary upgrades for 9.0 was a big features, and got
mentioned in the press release, but let's not kid ourselves that we
aren't going down a road that might be paved with pain.

We have explored all sorts of ideas to mitigate the pain, like new data
type oids and reading (writing?) old data format pages, but that is all
untested territory.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-09-23 19:20:17 Re: Why is time with timezone 12 bytes?
Previous Message Pavel Stehule 2010-09-23 18:56:53 Re: wip: functions median and percentile