Re: Versioning policy and pg_upgrade

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.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company