pg_upgrade pain; was Re: Why is time with timezone 12 bytes?
От | Bruce Momjian |
---|---|
Тема | pg_upgrade pain; was Re: Why is time with timezone 12 bytes? |
Дата | |
Msg-id | 201009231920.o8NJKFg09586@momjian.us обсуждение исходный текст |
Ответ на | Re: Why is time with timezone 12 bytes? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_upgrade pain; was Re: Why is time with timezone
12 bytes?
Re: pg_upgrade pain; was Re: Why is time with timezone12 bytes? |
Список | pgsql-hackers |
Robert Haas wrote: > On Thu, Sep 23, 2010 at 1:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@gmail.com> writes: > >> On Thu, Sep 23, 2010 at 1:29 PM, Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: