On Wed, May 31, 2017 at 3:02 PM, Shubham Barai <shubhambara...@gmail.com> wrote:
> I have been accepted as GSoC student for the project "Explicitly support > predicate locks in index access methods besides b-tree". I want to share my > approach for implementation of page level predicate locking in gist index. For the benefit of all following the discussion, implementing support in an index AM conceptually consists of two things: (1) Any scan with user-visible results must create SIRead predicate locks on "gaps" scanned. (For example, a scan just to find an insertion spot for an index entry does not generally count, whereas a scan to satisfy a user "EXISTS" test does.) (2) Any insert into the index must CheckForSerializableConflictIn() at enough points that at least one of them will detect an overlap with a predicate lock from a preceding scan if the inserted index entry might have changed the results of that preceding scan. Detecting such a conflict does not automatically result in a serialization failure, but is only part of tracking the information necessary to make such a determination. All that is handled by the existing machinery if the AM does the above. With a btree index, locking gaps at the leaf level is normally sufficient, because both scan and insertion of an index entry must descend that far. > The main difference between b-tree and gist index while searching for a > target tuple is that in gist index, we can determine if there is a match or > not at any level of the index. Agreed. A gist scan can fail at any level, but for that scan to have produced a different result due to insertion of an index entry, *some* page that the scan looked at must be modified. > The simplest way to do that will be by inserting a call for > prdicatelockpage() in gistscanpage(). Yup. > Insertion algorithm also needs to check for conflicting predicate locks at > each level of the index. Yup. > We can insert a call for CheckForSerializableConflictIn() at two places in > gistdoinsert(). > > 1. after acquiring an exclusive lock on internal page (in case we are trying > to replace an old search key) > > 2. after acquiring an exclusive lock on leaf page > > If there is not enough space for insertion, we have to copy predicate lock > from an old page to all new pages generated after a successful split > operation. For that, we can insert a call for PredicateLockPageSplit() in > gistplacetopage(). That all sounds good. When you code a patch, don't forget to add tests to src/test/isolation. Do you need any help getting a development/build/test environment set up? -- 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
