On Mon, May 02, 2005 at 02:12:33PM -0400, Merlin Moncure wrote: > > "Merlin Moncure" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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?" ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match