Re: [HACKERS] Setting pd_lower in GIN metapage

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Setting pd_lower in GIN metapage
Дата
Msg-id 28329.1497882664@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Setting pd_lower in GIN metapage  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Setting pd_lower in GIN metapage  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Mon, Jun 19, 2017 at 11:37 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> What are some arguments against setting pd_lower in the GIN metapage as
>> follows?

> Actually, hash index also has similar code (See _hash_init_metabuffer)
> and I see no harm in doing this at similar other places.

Seems reasonable.

>> How about porting such a change to the back-branches if we do this at all?
>> The reason I'm asking is that a certain backup tool relies on pd_lower
>> values of data pages (disk blocks in relation files that are known to have
>> a valid PageHeaderData) to be correct to discard the portion of every page
>> that supposedly does not contain any useful information.  The assumption
>> doesn't hold in the case of GIN metapage, so any GIN indexes contain
>> corrupted metapage after recovery (metadata overwritten with zeros).

I'm not in favor of back-porting such a change.  Even if we did, it would
only affect subsequently-created indexes not existing ones.  That means
your tool has to cope with an unset pd_lower in any case --- and will for
the foreseeable future, because of pg_upgrade.

I'd suggest a rule like "if pd_lower is smaller than SizeOfPageHeaderData
then don't trust it, but assume all of the page is valid data".
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] drop operator class..using .. left dependency behind.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] BUG: pg_dump generates corrupted gzip file in Windows