Re: 16-bit page checksums for 9.2
| От | Robert Haas |
|---|---|
| Тема | Re: 16-bit page checksums for 9.2 |
| Дата | |
| Msg-id | CA+TgmoaPR2WR=0+QjyvOTPs8LDBoiq73Bo4iRhg+XqS1AZmW8g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 16-bit page checksums for 9.2 (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
| Ответы |
Re: 16-bit page checksums for 9.2
|
| Список | pgsql-hackers |
On Wed, Feb 29, 2012 at 2:33 PM, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > On 29.02.2012 21:30, Robert Haas wrote: >> >> On Wed, Feb 29, 2012 at 2:18 PM, Alvaro Herrera >> <alvherre@commandprompt.com> wrote: >>> >>> Note that if we want such an utility to walk and transform pages, we >>> probably need a marker in the catalogs somewhere so that pg_upgrade can >>> make sure that it was done in all candidate tables -- which is something >>> that we should get in 9.2 so that it can be used in 9.3. Such a marker >>> would also allow us get rid of HEAP_MOVED_IN and HEAP_MOVED_OUT. >> >> >> Getting rid of HEAP_MOVED_IN and HEAP_MOVED_OUT would be really nice, >> but I don't see why we need to squeeze anything into 9.2 for any of >> this. pg_upgrade can certainly handle the addition of a new pg_class >> column, and can arrange for in-place upgrades from pre-9.3 versions to >> 9.3 to set the flag to the appropriate value. > > The utility would run in the old cluster before upgrading, so the the flag > would have to be present in the old version. pg_upgrade would check that the > flag is set, refusing to upgrade if it isn't, with an error like "please run > pre-upgrade utility first". I find that a pretty unappealing design; it seems to me it'd be much easier to make the new cluster cope with everything. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: