Re: Transaction-scope advisory locks

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: Transaction-scope advisory locks
Дата
Msg-id 4D072B23.8090409@cs.helsinki.fi
обсуждение исходный текст
Ответ на Re: Transaction-scope advisory locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Transaction-scope advisory locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko.tiikkaja@cs.helsinki.fi>  writes:
>> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
>>> 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:
>
> Uh, I don't think so.  It sure looks like you have changed the user
> lockmethod to be transactional, ie, auto-release on commit/abort.

I was under the impression that passing sessionLock=true to 
LockAcquire(), combined with allLocks=false to LockReleaseAll() would be 
enough to prevent that from happening.  My tests seem to agree with this.

Am I missing something?


Regards,
Marko Tiikkaja


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

Предыдущее
От: Jan Urbański
Дата:
Сообщение: Re: hstores in pl/python
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: pg_execute_from_file, patch v10