On Thu, Feb 16, 2017 at 6:19 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > Specifically, DeleteChildTargetLocks() assumes it can walk > MySerializableXact->predicateLocks and throw away locks that are > covered by a new lock (ie throw away tuple locks because a covering > page lock has been acquired) without let or hindrance until it needs > to modify the locks themselves. That assumption doesn't hold up with > that last patch and will require a new kind of mutual exclusion. I > wonder if the solution is to introduce an LWLock into each > SERIALIZABLEXACT object, so DeleteChildTargetLocks() can prevent > workers from stepping on each others' toes during lock cleanup. An > alternative would be to start taking SerializablePredicateLockListLock > in exclusive rather than shared mode, but that seems unnecessarily > coarse.
Here is a patch to do that, for discussion. It adds an LWLock to each SERIALIZABLEXACT, and acquires it after SerializablePredicateListLock and before any predicate lock partition lock. It doesn't bother with that if not in parallel mode, or in the cases where SerializablePredicateListLock is held exclusively. This prevents parallel query workers and leader from stepping on each others' toes when manipulating the predicate list. The case in CheckTargetForConflictsIn is theoretical for now since we don't support writing in parallel query yet. The case in CreatePredicateLock is reachable by running a simple parallel sequential scan. The case in DeleteChildTargetLocks is for when we've acquired a new predicate lock that covers finer grained locks which can be dropped; that is reachable the same way again. I don't think it's required in ReleaseOneSerializableXact since it was already called in several places with an sxact other than the caller's, and deals with finished transactions. -- Thomas Munro http://www.enterprisedb.com
Description: Binary data
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers