Re: Duplicate Item Pointers in Gin index

On Wed, Feb 21, 2018 at 3:02 PM, R, Siva <sivasubr(at)amazon(dot)com> wrote:
> Did you mean pin on the metapage buffer during ginInsertCleanup and not lock
> during addition of tuples to the accumulator? The exclusive lock on metapage
> buffer is released after reading/locking head of pending list and before we
> process pages/add tuples to the accumulator in ginInsertCleanup [1].

AFAICT, nobody ever holds just a pin on the metapage as some kind of
interlock (since nobody else ever acquires a "super exclusive lock" on
the metapage -- if anybody else ever did that, then simply holding a
pin might make sense as a way of blocking the "super exclusive" lock
acquisition). Maybe you're thinking of the root page of posting trees?

I think that Sawada-san simply means that holding an ExclusiveLock on
the metapage makes writers block each other, and concurrent VACUUMs.
At least, for as long as they're in ginInsertCleanup().

BTW, are you aware of this basic fact about GIN?:

/*
* First, scan the pending list and collect any matching entries into the
* bitmap. After we scan a pending item, some other backend could post it
* into the main index, and so we might visit it a second time during the
* main scan. This is okay because we'll just re-set the same bit in the
* bitmap. (The possibility of duplicate visits is a major reason why GIN
* can't support the amgettuple API, however.) Note that it would not do
* to scan the main index before the pending list, since concurrent
* cleanup could then make us miss entries entirely.
*/

(This comment is from gingetbitmap().)

> The metapage (not metapage buffer) is locked using LockPage upon entry
> in ginInsertCleanup and unlocked after processing of pending list is complete.
> Does that prevent concurrent insertions into the pending list?

It's supposed to be. I suggested that there might be a similar though
distinct problem there, right before discussion trailed off [1] --
"The metapage HW lock is sufficient for writers to block writers, but
AFAICT it is not sufficient for writers to block readers."

Is that related to what you're asking about?

[1] https://www.postgresql.org/message-id/CAH2-Wz%3DGTnAPzEEZqYELOv3h1Fxpo5xhMrBP6aMGEKLKv95csQ%40mail.gmail.com
--
Peter Geoghegan