Thread: Versioning policy and pg_upgrade
I noticed that the versioning policy page (http://www.postgresql.org/support/versioning) mentions that for upgrading between major versions, a dump/reload of the database is needed. Might we want to add a note in there about the use of pg_upgrade when upgrading from 8.3+ to 8.4+? I think some potential users might see a dump/reload as a deal-breaker. -- Thom Brown Registered Linux user: #516935
On Wed, Aug 11, 2010 at 10:39, Thom Brown <thom@linux.com> wrote: > I noticed that the versioning policy page > (http://www.postgresql.org/support/versioning) mentions that for > upgrading between major versions, a dump/reload of the database is > needed. Might we want to add a note in there about the use of > pg_upgrade when upgrading from 8.3+ to 8.4+? I think some potential > users might see a dump/reload as a deal-breaker. Definitely. Care to suggest a wording or even a patch? ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 16 August 2010 13:39, Magnus Hagander <magnus@hagander.net> wrote: > On Wed, Aug 11, 2010 at 10:39, Thom Brown <thom@linux.com> wrote: >> I noticed that the versioning policy page >> (http://www.postgresql.org/support/versioning) mentions that for >> upgrading between major versions, a dump/reload of the database is >> needed. Might we want to add a note in there about the use of >> pg_upgrade when upgrading from 8.3+ to 8.4+? I think some potential >> users might see a dump/reload as a deal-breaker. > > Definitely. Care to suggest a wording or even a patch? ;) > Tsk.. I forgot that I had started writing minor changes for the site before. I'll revisit it this evening. But I propose expanding it to read: "Major releases usually change the internal format of system tables and data files. These changes are often complex, so we don't maintain backward compatibility for data files. A dump/reload of the database cluster is required for major upgrades for upgrading from 8.2 or earlier. For upgrading from version 8.3 and later, there is the option to use pg_upgrade (also known as pg_migrator prior to version 9.0), capable of in-place upgrades. This means, for example, you can upgrade any minor version of 8.3 to 8.4 without having to perform a full backup and restore, resulting in a significantly faster upgrade." Too wordy? -- Thom Brown Registered Linux user: #516935
Thom Brown <thom@linux.com> writes:
> But I propose expanding it to read:
> "Major releases usually change the internal format of system tables
> and data files. These changes are often complex, so we don't maintain
> backward compatibility for data files. A dump/reload of the database
> cluster is required for major upgrades for upgrading from 8.2 or
> earlier. For upgrading from version 8.3 and later, there is the
> option to use pg_upgrade (also known as pg_migrator prior to version
> 9.0), capable of in-place upgrades. This means, for example, you can
> upgrade any minor version of 8.3 to 8.4 without having to perform a
> full backup and restore, resulting in a significantly faster upgrade."
> Too wordy?
I don't really think that pg_upgrade should be recommended for 8.3 to
8.4 upgrades. There are too many limitations and it's not been well
tested. I don't even trust it very much yet for 8.4 to 9.0 updates...
regards, tom lane
On 16 August 2010 15:28, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Thom Brown <thom@linux.com> writes: >> But I propose expanding it to read: > >> "Major releases usually change the internal format of system tables >> and data files. These changes are often complex, so we don't maintain >> backward compatibility for data files. A dump/reload of the database >> cluster is required for major upgrades for upgrading from 8.2 or >> earlier. For upgrading from version 8.3 and later, there is the >> option to use pg_upgrade (also known as pg_migrator prior to version >> 9.0), capable of in-place upgrades. This means, for example, you can >> upgrade any minor version of 8.3 to 8.4 without having to perform a >> full backup and restore, resulting in a significantly faster upgrade." > >> Too wordy? > > I don't really think that pg_upgrade should be recommended for 8.3 to > 8.4 upgrades. There are too many limitations and it's not been well > tested. I don't even trust it very much yet for 8.4 to 9.0 updates... > Okay, rather than a recommendation, we could present it as an option some may wish to consider? Then link it to the pg_upgrade page in the documentation. -- Thom Brown Registered Linux user: #516935
On Mon, 2010-08-16 at 13:59 +0100, Thom Brown wrote: > But I propose expanding it to read: > > "Major releases usually change the internal format of system tables > and data files. These changes are often complex, so we don't maintain > backward compatibility for data files. A dump/reload of the database > cluster is required for major upgrades for upgrading from 8.2 or > earlier. For upgrading from version 8.3 and later, there is the > option to use pg_upgrade (also known as pg_migrator prior to version > 9.0), capable of in-place upgrades. This means, for example, you can > upgrade any minor version of 8.3 to 8.4 without having to perform a > full backup and restore, resulting in a significantly faster upgrade." > > Too wordy? Yes :D (well I think so): "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." JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
On Mon, 2010-08-16 at 13:59 +0100, Thom Brown wrote: > But I propose expanding it to read: > > "Major releases usually change the internal format of system tables > and data files. These changes are often complex, so we don't maintain > backward compatibility for data files. A dump/reload of the database > cluster is required for major upgrades for upgrading from 8.2 or > earlier. For upgrading from version 8.3 and later, there is the > option to use pg_upgrade (also known as pg_migrator prior to version > 9.0), capable of in-place upgrades. This means, for example, you can > upgrade any minor version of 8.3 to 8.4 without having to perform a > full backup and restore, resulting in a significantly faster upgrade." > > Too wordy? Yes :D (well I think so): "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." JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
Tom Lane wrote: > Thom Brown <thom@linux.com> writes: > > But I propose expanding it to read: > > > "Major releases usually change the internal format of system tables > > and data files. These changes are often complex, so we don't maintain > > backward compatibility for data files. A dump/reload of the database > > cluster is required for major upgrades for upgrading from 8.2 or > > earlier. For upgrading from version 8.3 and later, there is the > > option to use pg_upgrade (also known as pg_migrator prior to version > > 9.0), capable of in-place upgrades. This means, for example, you can > > upgrade any minor version of 8.3 to 8.4 without having to perform a > > full backup and restore, resulting in a significantly faster upgrade." > > > Too wordy? > > I don't really think that pg_upgrade should be recommended for 8.3 to > 8.4 upgrades. There are too many limitations and it's not been well > tested. I don't even trust it very much yet for 8.4 to 9.0 updates... Hey, I heard that! ;-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 8/16/10 5:46 PM, Bruce Momjian wrote:
>> I don't really think that pg_upgrade should be recommended for 8.3 to
>> 8.4 upgrades. There are too many limitations and it's not been well
>> tested. I don't even trust it very much yet for 8.4 to 9.0 updates...
It's actually pretty well tested for to 9.0. A lot of the beta-testers
have been using it.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus <josh@agliodbs.com> writes:
>>> I don't really think that pg_upgrade should be recommended for 8.3 to
>>> 8.4 upgrades. There are too many limitations and it's not been well
>>> tested. I don't even trust it very much yet for 8.4 to 9.0 updates...
> It's actually pretty well tested for to 9.0. A lot of the beta-testers
> have been using it.
Well, I think it's now approaching releaseable quality for 8.4->9.0.
What I was objecting to was recommending the previous iteration with
any enthusiasm ...
regards, tom lane
On Wed, Aug 18, 2010 at 5:25 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 8/16/10 5:46 PM, Bruce Momjian wrote: >>> I don't really think that pg_upgrade should be recommended for 8.3 to >>> 8.4 upgrades. There are too many limitations and it's not been well >>> tested. I don't even trust it very much yet for 8.4 to 9.0 updates... > > It's actually pretty well tested for to 9.0. A lot of the beta-testers > have been using it. Beta testers are one thing; large numbers of production users are something else again. I believe it's better tested this time than it was last time around, but I wouldn't be prepared to bet against us finding more bugs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
> Beta testers are one thing; large numbers of production users are
> something else again. I believe it's better tested this time than it
> was last time around, but I wouldn't be prepared to bet against us
> finding more bugs.
I'm certain that we'll find more bugs. More or less indefinitely, in
fact; pg_upgrade is aiming at a moving target. However, I do have
confidence that it now works for 80-90% of users out of the box, which
is a considerable improvement over a year ago.
For that matter, I'm certain that within the next year we'll find at
least one bug in pg_dump/pg_restore. Nothing is bug-free; the bugs just
occur with less frequency.
-- -- Josh Berkus PostgreSQL Experts Inc.
http://www.pgexperts.com
Joshua D. Drake wrote: > On Mon, 2010-08-16 at 13:59 +0100, Thom Brown wrote: > > > But I propose expanding it to read: > > > > "Major releases usually change the internal format of system tables > > and data files. These changes are often complex, so we don't maintain > > backward compatibility for data files. A dump/reload of the database > > cluster is required for major upgrades for upgrading from 8.2 or > > earlier. For upgrading from version 8.3 and later, there is the > > option to use pg_upgrade (also known as pg_migrator prior to version > > 9.0), capable of in-place upgrades. This means, for example, you can > > upgrade any minor version of 8.3 to 8.4 without having to perform a > > full backup and restore, resulting in a significantly faster upgrade." > > > > Too wordy? > > Yes :D (well I think so): > > "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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + *** ./versioning.html.orig Fri Jan 28 10:50:25 2011 --- ./versioning.html Fri Jan 28 11:22:17 2011 *************** *** 13,19 **** </p> <p> ! Major releases usually change the internal format of system tables and data files. These changes are often complex, sowe don't maintain backward compatibility for data files. A dump/reload of the database is required for major upgrades. </p> <p> --- 13,19 ---- </p> <p> ! Major releases usually change the internal format of system tables and data files. These changes are often complex, sowe do not maintain backward compatibility of all stored data. A dump/reload of the database or use of the <a href="http://www.postgresql.org/docs/current/static/pgupgrade.html">pg_upgrade</a>module is required for major upgrades. </p> <p>
On Fri, Jan 28, 2011 at 11:52 AM, Bruce Momjian <bruce@momjian.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
Robert Haas wrote: > On Fri, Jan 28, 2011 at 11:52 AM, Bruce Momjian <bruce@momjian.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Jan 28, 2011 at 9:50 PM, Bruce Momjian <bruce@momjian.us> wrote: >> 1. This is the wrong mailing list for this discussion. > > It's a web site patch. Where should it be posted? Oh, sorry. I thought we were talking about the docs. >> 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. It's not that much more than you wrote, and it has the redeeming value of being accurate... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 28 January 2011 20:55, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Jan 28, 2011 at 11:52 AM, Bruce Momjian <bruce@momjian.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. Only some major releases change the internal format? I thought it was best to assume it always did that. "In cases where the data file formats have not changed" Don't you mean "have changed"? "pg_upgrade can also be used for major upgrade version upgrades" That doesn't read very well. Perhaps remove the first "upgrade". -- Thom Brown Twitter: @darkixion IRC (freenode): dark_ixion Registered Linux user: #516935
Robert Haas wrote: > On Fri, Jan 28, 2011 at 9:50 PM, Bruce Momjian <bruce@momjian.us> wrote: > >> 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. > > It's not that much more than you wrote, and it has the redeeming value > of being accurate... I added five words. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian wrote: > Robert Haas wrote: > > On Fri, Jan 28, 2011 at 9:50 PM, Bruce Momjian <bruce@momjian.us> wrote: > > >> 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. > > > > It's not that much more than you wrote, and it has the redeeming value > > of being accurate... > > I added five words. To followup again, you obviously thought you were writing for our docs, not the web site. I will incorporate your wording into the new merged upgrade doc chapter or into pg_upgrade's manual page. We don't normally cover technical details like this on the web site, which is why I think just mentioning pg_upgrade and a link to it is enough there. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, Jan 29, 2011 at 8:34 AM, Thom Brown <thom@linux.com> wrote: >> 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. > > Only some major releases change the internal format? I thought it was > best to assume it always did that. > > "In cases where the data file formats have not changed" > > Don't you mean "have changed"? No. The point is, the reason pg_upgrade can work is that the format of the data files haven't changed. The catalogs are different, but all the heaps and indexes are OK (except if you're upgrading from a version where they're not, in which case life sucks). > "pg_upgrade can also be used for major upgrade version upgrades" > > That doesn't read very well. Perhaps remove the first "upgrade". Yeah, typo, sorry. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote: > On Fri, Jan 28, 2011 at 11:52 AM, Bruce Momjian <bruce@momjian.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. I have incorporated your ideas into the pg_upgrade docs. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian wrote: > Joshua D. Drake wrote: > > On Mon, 2010-08-16 at 13:59 +0100, Thom Brown wrote: > > > > > But I propose expanding it to read: > > > > > > "Major releases usually change the internal format of system tables > > > and data files. These changes are often complex, so we don't maintain > > > backward compatibility for data files. A dump/reload of the database > > > cluster is required for major upgrades for upgrading from 8.2 or > > > earlier. For upgrading from version 8.3 and later, there is the > > > option to use pg_upgrade (also known as pg_migrator prior to version > > > 9.0), capable of in-place upgrades. This means, for example, you can > > > upgrade any minor version of 8.3 to 8.4 without having to perform a > > > full backup and restore, resulting in a significantly faster upgrade." > > > > > > Too wordy? > > > > Yes :D (well I think so): > > > > "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. FYI, I am still waiting for someone to apply this patch. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Thu, Feb 3, 2011 at 00:26, Bruce Momjian <bruce@momjian.us> wrote: > Bruce Momjian wrote: >> Joshua D. Drake wrote: >> > On Mon, 2010-08-16 at 13:59 +0100, Thom Brown wrote: >> > >> > > But I propose expanding it to read: >> > > >> > > "Major releases usually change the internal format of system tables >> > > and data files. These changes are often complex, so we don't maintain >> > > backward compatibility for data files. A dump/reload of the database >> > > cluster is required for major upgrades for upgrading from 8.2 or >> > > earlier. For upgrading from version 8.3 and later, there is the >> > > option to use pg_upgrade (also known as pg_migrator prior to version >> > > 9.0), capable of in-place upgrades. This means, for example, you can >> > > upgrade any minor version of 8.3 to 8.4 without having to perform a >> > > full backup and restore, resulting in a significantly faster upgrade." >> > > >> > > Too wordy? >> > >> > Yes :D (well I think so): >> > >> > "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. > > FYI, I am still waiting for someone to apply this patch. Seems Dave applied this without acknowledging it here. I accidentally reversed it, and have now put it back in again :-) Sorry about the delay and the confusion. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/