I've been working on a DSS query resource management module for Bizgres
[1], which is currently in the code and working (Bizgres is based on 8.1.x).
...and therein lies my new problem - updating to the 8.2 codebase. The
issue is that I have used the LockMgrLock [2] to:
1/ Manage the (resource) locks that provide the query queuing functionality.
2/ Protect shared memory structures (the queues and portal/statement
hashes) that provide the modified conflict routines and data for the queues.
However in 8.2 the partition lock changes break this design. So I'm
thinking of the following;
1/ Use the partition lock for the (resource) locks - as they live in the
lock hash table along with the standard and advisory locks.
2/ Protect shared memory structures (the queues and portal/statement
hashes) with a new lwlock (ResLockMgrLock).
This complicates the code somewhat, with what looks like a lot more
lwlock/unlock oprations - but may actually be better for concurrency as
we have less contention for an single lock (I think).
The other approach I wondered about was arranging for the resource locks
and related data structures to all use an *additional* partition lock -
which would mean faking a LOCKTAG that always hashed to
NUM_LOCK_PARTITIONS, and using that everywhere in the resource code...
Comments welcome - as I'm scratching my head somewhat about this :-)!
Cheers
Mark
[1] http://archives.postgresql.org/pgsql-hackers/2006-07/msg00133.php
[2] The main reason that a new lwlock was not used was that we need to
be able to do deadlock checking between resource and standard locks.
~
~