Re: pg_locks needs a facelift - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: pg_locks needs a facelift
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3415C270D@Herge.rcsinc.local
Whole thread Raw
In response to pg_locks needs a facelift  (Tom Lane)
Responses Re: pg_locks needs a facelift  (Tom Lane)
Re: pg_locks needs a facelift  ("Jim C. Nasby")
List pgsql-hackers
> "Merlin Moncure" <> 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


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement
Next
From: Bruce Momjian
Date:
Subject: Re: [pgsql-advocacy] Increased company involvement