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

From Moon, Insung
Subject Re: Wrong value in metapage of GIN INDEX.
Date
Msg-id CAEMmqBtQWHEt0Me+dHDnE_37K9Re46RQAGYW977Lf8m6qEC6Uw@mail.gmail.com
Whole thread Raw
In response to Re: Wrong value in metapage of GIN INDEX.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Dear Tom Lane.

On Tue, Nov 5, 2019 at 3:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "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.

Thank you for review and push to patch.
Yes. I don't think it's a bug that has a big impact like your opinion.

Best regards.
Moon.

>
>                         regards, tom lane



pgsql-hackers by date:

Previous
From: "Moon, Insung"
Date:
Subject: Exposure related to GUC value of ssl_passphrase_command
Next
From: Grigory Smolkin
Date:
Subject: Re: [proposal] recovery_target "latest"