Re: Versioning policy and pg_upgrade

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: jd(at)commandprompt(dot)com, Thom Brown <thom(at)linux(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, "w^3" <pgsql-www(at)postgresql(dot)org>
Subject: Re: Versioning policy and pg_upgrade
Date: 2011-01-29 02:50:35
Message-ID: 201101290250.p0T2oZ214225@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

Robert Haas wrote:
> On Fri, Jan 28, 2011 at 11:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> "A Major release changes the internal data format of the cluster.
> >> Due to this change a dump/reload of the cluster is required for major
> >> upgrades for upgrading from 8.2 or earlier.
> >>
> >> If upgrading from version 8.3 and later, certain installs may be able to
> >> use pg_upgrade (previously named pg_migrator). If pg_upgrade is
> >> compatible with your cluster (see the docs) you will able to perform an
> >> in-place upgrades. Although downtime is still required, this is much
> >> quicker than a dump/restore."
> >
> > Based on this discussion from August, I suggest the following patch be
> > applied to versioning.html. ?It mentions pg_upgrade as an major upgrade
> > option and links to the pg_upgrade page that has all the details.
>
> 1. This is the wrong mailing list for this discussion.

It's a web site patch. Where should it be posted?

> 2. I think the whole point here is that we've had a policy change: we
> are now making an effort to maintain backward compatibility for data
> files, though not for system tables. The docs should reflect that.
>
> Maybe something like:
>
> Major releases usually change the format of system tables. These
> changes are often complex, so we do not maintain backward
> compatibility. Our dump and reload tools do maintain backward
> compatibility and are the most reliable way to perform a major version
> upgrade. Some major releases also change the internal format of data
> files; however, in recent releases, we have made an attempt to
> minimize such changes. In cases where the data file formats have not
> changed, pg_upgrade can also be used for major upgrade version
> upgrades; this is typically much faster than a dump and reload.

That seems quite detailed for the web site. If we want that I think we
should add those details to the pg_upgrade manual page. Some of that is
already there.

--
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-www by date

  From Date Subject
Next Message Robert Haas 2011-01-29 13:16:50 Re: Versioning policy and pg_upgrade
Previous Message Robert Haas 2011-01-28 20:55:47 Re: Versioning policy and pg_upgrade