Re: pg_locks needs a facelift

On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote:
> > "Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> > Fair enough, although I think that at least one major application of
> > user locks would be equivalent to tuple locks.  Somebody was asking
> > for named user locks in the previous thread, and the easiest way to
> > get that is to make a table containing just lock names, and then lock
> > on the CTIDs of that table.  Since there would be no reason to allow
> > UPDATE or DELETE in such a table, the putative instability of CTID
> > doesn't really matter.
> 
> This is fine, but relying on structures outside of shared memory is a
> fairly hefty price.  User locks are very fast and tight and incur zero
> maintenance overhead...with a table you have to consider vacuuming
> strategies + possible reindex for the unique constraint...bleh.  If the
> lock table was not synced and auto-vacuumed, then maybe it could work.
> I also wonder if there would be a race condition if someone tried to
> acquire ctid based named lock at the same time a user lock with the same
> value, unless ctid locks were maintained in a separate hash table.

Well, there's nothing that says you have to actually refer to locks by
name. When I proposed this what I proposed is that the userlock module
provide a dedicated means to map a lock name to a lock number, and
reserve one of the 'lock spaces' (the 16 bit number) for this use, just
as one of them is currently reserved for locks based on OID. But I also
can't think of any reason why lock names need to be persistent, so I
imagine you could store a list of lock names in shared memory with no
backing storage.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"