On Thu, Jun 1, 2017 at 12:49 AM, Andrew Borodin <boro...@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.80...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
