Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?

Hello!

Sorry, I should have expressed my thoughts in more detail, as they don't
matter as much as the time you took to answer.

>I don't quite read it as covering IOS. To me, the comment is more
> along the lines of (extensively extended):

My idea was just to add a few more details about the locking rule, such as:

* safe to apply LP_DEAD hints to the page later. This allows us to drop
* the pin for MVCC scans (except in cases of index-only scans due to XXX),
which allows vacuum to avoid blocking.

>   I think this "MVCC scan" even means non-IOS scan

Maybe, but I think it’s better to clarify that, since IOS scans still use
the MVCC snapshot. For me, a non-MVCC scan is something like SnapshotSelf
or SnapshotDirty.

>  Why would it be incorrect or invalid to kill items in an index-only scan?

Oh, I was comparing the logic to that of btree and somehow made a logical
error in my conclusions. But at least I hope I got some useful thoughts out
of it - since we have a pin during gistkillitems in the case of IOS, we can
ignore the "if (BufferGetLSNAtomic(buffer) != so->curPageLSN)" check in
that case because vacuum is locked.
It is not a compensation for a performance penalty caused by buffer pin
during IOS, but at least something.

I hope this time my conclusions are correct :)

Thanks,
Mikhail.