On Thu, Jun 1, 2017 at 12:49 AM, Andrew Borodin <borodin@octonica.com> wrote:
> First, I just do not know, can VACUUM erase page with predicate lock?
For handling in btree, see:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/nbtree/nbtpage.c;h=f815fd40b20e98a88cb2fb5c71005ea125a459c9;hb=refs/heads/master#l1406
Note also this discussion:
https://www.postgresql.org/message-id/4D669122.80904@enterprisedb.com
It doesn't look like we ever got to the optimization Heikki
suggested in that post, so on rare occasions we could see a false
positive from this. Perhaps we should give this another look while
we're in the AMs.
> Right now, GiST never deletes pages, as far as I know, so this
> question is only matter of future compatibility.
ok
> Second, when we are doing GiST inserts, we can encounter unfinished
> split. That's not a frequent situation, but still. Should we skip
> finishing split or should we add it to collision check too?
When a page is split, I think you need to call
PredicateLockPageSplit() before it gets to the point that an insert
to get to it.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/