Re: pg_locks needs a facelift

> "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)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.

Interesting aside: you can get very similar functionality by abusing
pg_listener...not that I'd suggest doing that however ;).

> Certainly the current contrib/userlock code could stand a rewrite.
> Or more likely, addition of new functions --- we should deprecate
> the old ones, but I see no need to remove 'em right away.

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.

Merlin