Re: Wrong value in metapage of GIN INDEX. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Wrong value in metapage of GIN INDEX.
Date
Msg-id 2198.1572893702@sss.pgh.pa.us
Whole thread Raw
In response to RE: Wrong value in metapage of GIN INDEX.  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Responses Re: Wrong value in metapage of GIN INDEX.  ("Moon, Insung" <tsukiwamoon.pgsql@gmail.com>)
List pgsql-hackers
"imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com> writes:
> Moon-san, kuroda.keisuke-san
> On Thu, Aug 29, 2019 at 8:20 AM, Moon, Insung wrote:
>> The patch is very simple.
>> Fix to increase the value of nEntries only when a non-duplicate GIN index leaf added.

> Does nentries show the number of entries in the leaf pages?
> If so, the fix seems to be correct.

I looked at this issue.  The code in ginEntryInsert is not obviously wrong
by itself; it depends on what you think nEntries is supposed to count.
However, ginvacuum.c updates nEntries to the sum of PageGetMaxOffsetNumber()
across all the index's leaf pages, ie the number of surviving leaf items.

It's hard to see how ginvacuum could reverse-engineer a value that would
match what ginEntryInsert is doing, so probably we ought to define
nEntries as the number of leaf items, which seems to make the proposed
patch correct.  (It could use a bit more commentary though.)

I'm inclined to apply this to HEAD only; it doesn't seem significant
enough to justify back-patching.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Missed check for too-many-children in bgworker spawning
Next
From: Andres Freund
Date:
Subject: Re: Missed check for too-many-children in bgworker spawning