| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Subject: | Re: advisory locks and permissions |
| Date: | 2006-09-22 19:28:54 |
| Message-ID: | 10337.1158953334@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-09-22 19:31:21 | Re: advisory locks and permissions |
| Previous Message | Tom Lane | 2006-09-22 19:20:01 | Re: advisory locks and permissions |