"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
>> "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.
What vacuuming strategy? It's a constant table, at least in my view of
the usage. I see no reason for the table lookups to be part of the
performance critical path, either --- if you're grabbing and releasing a
particular lock a lot, you could read the needed CTID and cache it on
the application side.
In any case, we are certainly *not* expanding LOCKTAG to the point where
it can hold random user-defined strings ;-)
> 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.
This would be a matter of making sure you didn't use conflicting LOCKTAG
bit patterns for different purposes. In practice the easiest way to do
that would be to add more LockTagType enum values, which is trivial
enough now. (I'll probably fix pg_locks so that if it doesn't recognize
a particular LockTagType value, it prints the locktag as the numeric
value of the tag, rather than falling back to something unhelpful like
"unknown". This way you could make some use of freshly-invented tag
values without any changes at all in the core backend.)
> well, the old ones are GPL. I've made a few attempts to contact the
> original author...he's MIA. Since 95% of the implementation is in the
> backend, it seems odd to have a GPL interface.
I agree. Wasn't it you that was proposing to rewrite the module from
scratch to eliminate the GPL restriction?
regards, tom lane