Re: Transaction-scope advisory locks

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Transaction-scope advisory locks
Дата
Msg-id 1292286926.2737.3585.camel@ebony
обсуждение исходный текст
Ответ на Re: Transaction-scope advisory locks  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Ответы Re: Transaction-scope advisory locks  (Andrew Dunstan <andrew@dunslane.net>)
Re: Transaction-scope advisory locks  (Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>)
Список pgsql-hackers
On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
> > On 13 December 2010 23:52, Marko Tiikkaja<marko.tiikkaja@cs.helsinki.fi>wrote:
> >> So, thoughts?
> >>
> > In my opinion changing current behavior is not a good idea. I know some
> > software that relies on current behavior and this would break it. Maybe add
> > that as an option, or add another type of advisory lock?
> 
> Oh, I forgot to mention.  The patch doesn't change any existing 
> behaviour; the new behaviour can be invoked only by adding a new boolean 
> argument:
> 
> SELECT pg_advisory_lock(1, false);

Don't like adding a boolean. Nobody remembers what it is for and we have
bugs. How about pg_advisory_xact_lock()

> The lock space is the same though, but I don't feel strongly about it.

Same lock space is good. Easy to separate if required.

Explicitly nameable lock spaces would be even better, since if multiple
applications use them you get strange and unmanageable contention.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: rest of works for security providers in v9.1
Следующее
От: Robert Haas
Дата:
Сообщение: Re: SynchRep; wait-forever and shutdown