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
|
Список | 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 по дате отправления: