Re: Wrong value in metapage of GIN INDEX.
От | Moon, Insung |
---|---|
Тема | Re: Wrong value in metapage of GIN INDEX. |
Дата | |
Msg-id | CAEMmqBtQWHEt0Me+dHDnE_37K9Re46RQAGYW977Lf8m6qEC6Uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Wrong value in metapage of GIN INDEX. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: