> "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.

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

"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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

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?"

---------------------------(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