Re: Block-level CRC checks

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Block-level CRC checks
Дата
Msg-id 603c8f070912040700l3666cbf8n25b4ba6fbbeb1e3b@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Block-level CRC checks  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Block-level CRC checks  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Fri, Dec 4, 2009 at 9:48 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Heikki Linnakangas escribió:
>> Simon Riggs wrote:
>> > On Fri, 2009-12-04 at 09:52 -0300, Alvaro Herrera wrote:
>> >
>> >> BTW with VACUUM FULL removed I assume we're going to get rid of
>> >> HEAP_MOVED_IN and HEAP_MOVED_OFF too, right?
>> >
>> > Much as I would like to see those go, no. VF code should remain for some
>> > time yet, IMHO.
>>
>> I don't think we need to keep VF code otherwise, but I would leave
>> HEAP_MOVED_IN/OFF support alone for now for in-place upgrade. Otherwise
>> we need a pre-upgrade script or something to scrub them off.
>
> CRCs are going to need scrubbing anyway, no?  Oh, but you're assuming
> that CRCs are optional, so not everybody would need that, right?

If we can make not only the validity but also the presence of the CRC
field optional, it will simplify things greatly for in-place upgrade,
I think, because the upgrade won't itself require expanding the page.
Turning on the CRC functionality for a particular table may require
expanding the page, but that's a different problem.  :-)

Have we thought about what other things have changed between 8.4 and
8.5 that might cause problems for in-place upgrade?

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Block-level CRC checks
Следующее
От: Jeff
Дата:
Сообщение: Re: First feature patch for plperl - draft [PATCH]