| 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 08:30:27 | 
| Message-ID: | 4D072B23.8090409@cs.helsinki.fi | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2010-12-14 4:23 AM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-12-14 09:01:50 | Re: pg_execute_from_file, patch v10 | 
| Previous Message | Jan Urbański | 2010-12-14 07:37:45 | Re: hstores in pl/python |