[HACKERS] Setting pd_lower in GIN metapage - Mailing list pgsql-hackers

From Amit Langote
Subject [HACKERS] Setting pd_lower in GIN metapage
Date
Msg-id 0d273805-0e9e-ec1a-cb84-d4da400b8f85@lab.ntt.co.jp
Whole thread Raw
Responses Re: [HACKERS] Setting pd_lower in GIN metapage  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
What are some arguments against setting pd_lower in the GIN metapage as
follows?

GinMetaPageData *metad = GinPageGetMeta(page);

((PageHeader) page)->pd_lower =   ((char *) metad + sizeof(GinMetaPageData)) - (char *) page;

I saw that _bt_initmetapage() does it, so was wondering why doesn't GIN.

How about porting such a change to the back-branches if we do this at all?I couldn't find any discussion in the
archivesabout this.  I read in
 
comments that server versions older than 9.4 didn't set pd_lower correctly
in any of GIN index pages, so relying on pd_lower value of GIN pages is
unreliable in general.

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).

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: [HACKERS] UPDATE of partition key
Next
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] BUG: pg_dump generates corrupted gzip file in Windows