Re: Transaction-scope advisory locks

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: Transaction-scope advisory locks
Дата
Msg-id 4D07DC31.2050307@cs.helsinki.fi
обсуждение исходный текст
Ответ на Re: Transaction-scope advisory locks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2010-12-14 7:05 PM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko.tiikkaja@cs.helsinki.fi>  writes:
>> On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
>>> 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?
>
> All the places that look at LockMethodData->transactional ?

As far as I can tell, every code path that looks at 
LockMethodData->transactional either has an explicit sessionLock boolean 
or looks whether owner == NULL to actually check whether the lock in 
question is a session lock or not instead of blindly trusting 
->transactional.


Regards,
Marko Tiikkaja


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]
Следующее
От: Robert Haas
Дата:
Сообщение: unlogged tables vs. GIST