From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
Cc: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, AgentM <agentm(at)themactionfaction(dot)com>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: advisory locks and permissions |
Date: | 2006-09-22 17:38:21 |
Message-ID: | 2105.1158946701@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
> On 9/22/06, Jim C. Nasby <jim(at)nasby(dot)net> wrote:
>> This is why I suggested we set aside some range of numbers that should
>> not be used. Doing so would allow adding a better-managed
>> numbering/naming scheme in the future.
> the whole point about advisory locks is that the provided lock space
> is unmanaged.
I think we forgot to document that the lock space is per-database; also,
wouldn't it be a good idea to specifically recommend that advisory locks
be used only in databases that are used just by one application, or a
few cooperating applications? The lack of any permissions checks makes
them fairly unsafe in databases that are used by multiple users.
I don't actually have a problem with the lack of security checks or
key range limitations --- I see advisory locks as comparable to large
objects, which are likewise permissions-free. It's an optional feature
and you just won't use it in databases where permission constraints are
a critical need. The thing that's bothering me is the relative ease of
accidental DoS to applications in *other* databases in the same cluster.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2006-09-22 17:42:48 | Re: advisory locks and permissions |
Previous Message | Andrew Dunstan | 2006-09-22 17:36:42 | Re: 8.3 Development Cycle |