From: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Szymon Guz <mabewlun(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transaction-scope advisory locks |
Date: | 2010-12-14 21:05:53 |
Message-ID: | 4D07DC31.2050307@cs.helsinki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2010-12-14 7:05 PM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-12-14 21:06:40 | unlogged tables vs. GIST |
Previous Message | Tom Lane | 2010-12-14 20:52:30 | Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH] |