Re: Versioning policy and pg_upgrade
От | Robert Haas |
---|---|
Тема | Re: Versioning policy and pg_upgrade |
Дата | |
Msg-id | AANLkTikFYY63HKcmXAKxGUf5Ssp+4d=+h8DLuDfdHHq0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Versioning policy and pg_upgrade (Thom Brown <thom@linux.com>) |
Список | pgsql-www |
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
В списке pgsql-www по дате отправления: