Hack on lock transfer stuff. gathertest
authorRobert Haas <rhaas@postgresql.org>
Sat, 30 Jan 2016 13:35:56 +0000 (08:35 -0500)
committerRobert Haas <rhaas@postgresql.org>
Mon, 1 Feb 2016 21:13:15 +0000 (16:13 -0500)
commit874b3b86a898d07beea6e2143ab9827153cc8fc0
tree9634e659e5ce849d59d0d1440f806b5fab6135da
parent1b4d0cffd00248df5c1c57239284e985ba82cf86
Hack on lock transfer stuff.

XXX: I don't think this is the right design.  It will require the workers
to wait for the leader to perform the associated lock acquisitions, and
then the leader will need to tell them, afterwards, that they can go exit.
There's no obvious way to make that signalling work.  Instead, I wonder if
we shouldn't including bookkeeping information in the PROCLOCK structures
somehow, so that the worker actually reassigns the locks to the leader
directly.  However, that has a couple of problems.  One is that the leader
might pick a bad time to die, orphaning locks.  Another is that the leader
wouldn't know how to associate the locks with its own resource owners.
Hmm, need to think more about this.
src/backend/access/transam/parallel.c
src/backend/storage/lmgr/lock.c
src/include/storage/lock.h