Re: Transaction-scope advisory locks - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: Transaction-scope advisory locks
Date
Msg-id 4D06BF79.5080605@cs.helsinki.fi
Whole thread Raw
In response to Re: Transaction-scope advisory locks  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 2010-12-14 2:35 AM +0200, Simon Riggs wrote:
> On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
>> 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:
>>
>> SELECT pg_advisory_lock(1, false);
>
> Don't like adding a boolean. Nobody remembers what it is for and we have
> bugs. How about pg_advisory_xact_lock()

That's the other option I was thinking of, but didn't like that too 
much.  But you're right about the boolean, it is a bit hard to remember 
which behaviour is which.

>> The lock space is the same though, but I don't feel strongly about it.
>
> Same lock space is good. Easy to separate if required.
>
> Explicitly nameable lock spaces would be even better, since if multiple
> applications use them you get strange and unmanageable contention.

I think something like this has been suggested in the past, and was 
rejected at that time.


Regards,
Marko Tiikkaja


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Transaction-scope advisory locks
Next
From: KaiGai Kohei
Date:
Subject: Re: rest of works for security providers in v9.1