Re: advisory locks and permissions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: advisory locks and permissions
Дата
Msg-id 2105.1158946701@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: advisory locks and permissions  ("Merlin Moncure" <mmoncure@gmail.com>)
Ответы Re: advisory locks and permissions  ("Merlin Moncure" <mmoncure@gmail.com>)
Список pgsql-hackers
"Merlin Moncure" <mmoncure@gmail.com> writes:
> On 9/22/06, Jim C. Nasby <jim@nasby.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: advisory locks and permissions
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: advisory locks and permissions