Re: advisory locks and permissions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: advisory locks and permissions
Date
Msg-id 10337.1158953334@sss.pgh.pa.us
Whole thread Raw
In response to Re: advisory locks and permissions  (Bruce Momjian <bruce@momjian.us>)
Responses Re: advisory locks and permissions  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> (b) we put up that pgfoundry module so that there would be a backward
>> compatible solution.  Won't be very backward compatible if the locks
>> look different in pg_locks.

> But is anyone going to know what userlocks is in 1-2 years?  We have few
> people using /contrib/userlocks, but in the future, I bet we have a lot
> more people using advisory locks, and being confused.

The reason they're "advisory" is that the current set of functions for
accessing them doesn't enforce anything.  That doesn't make the locks
themselves any more or less user-defined than they were before ---
certainly the pg_locks view has got nothing to do with whether they are
advisory or enforced.  I do not see a good reason to change it.

It might be worth mentioning in the description of the pg_xxx_lock
functions that the locks they acquire are shown as "userlock" in
pg_locks, but that seems sufficient.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: advisory locks and permissions
Next
From: Bruce Momjian
Date:
Subject: Re: advisory locks and permissions