Re: Transaction-scope advisory locks

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: Szymon Guz <mabewlun(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction-scope advisory locks
Date: 2010-12-14 00:35:26
Message-ID: 1292286926.2737.3585.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2010-12-14 at 01:14 +0200, Marko Tiikkaja wrote:
> On 2010-12-14 1:08 AM +0200, Szymon Guz wrote:
> > On 13 December 2010 23:52, Marko Tiikkaja<marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>wrote:
> >> So, thoughts?
> >>
> > 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:
>
> 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()

> 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.

--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-14 00:41:05 Re: SynchRep; wait-forever and shutdown
Previous Message Robert Haas 2010-12-14 00:32:50 Re: rest of works for security providers in v9.1