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
|
Список | 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 по дате отправления: