Re: advisory locks (was: 8.2 beta blockers)

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: advisory locks (was: 8.2 beta blockers)
Date: 2006-09-19 16:21:20
Message-ID: b42b73150609190921k79b5a682j5d1d5be342b98aa7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/19/06, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On 9/17/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > We have three possible choices for this: do nothing, install a
> > bug-compatible, allegedly-clean-room implementation in contrib:
> > http://archives.postgresql.org/pgsql-patches/2006-09/msg00077.php
> > or put a hopefully-cleaner design into core, eg per my suggestions here:
> > http://archives.postgresql.org/pgsql-hackers/2006-09/msg00467.php
> > I favor the third alternative, mainly because by changing the API
> > we remove all doubt as to whether any "intellectual property"
> > remains from the original GPL'd code. However, we've got to make up
> > our minds and get on with it.
>
> two questions: do we need both a shared and unshared variant of
> advisory_unlock (im guessing no)? also, are we exposing the mode in
> the int4/int4 signature or are all advisory locks assumed to be
> exclusive (if yes, which int4 is the lockmode).

also, is void pg_advisory_lock_shared(int8), etc. not better written as
void pg_advisory_lock_wait(int8). or even better, default
pg_advisory_lock to the 'wait' variant and explicitly declare
pg_advisory_lock_nowait(int8).

there are two things going on here: first, i think we are confusing
the concepts of lockmode and waitmode, and secondly since in most
other places wait locks are default with an optional nowait clause,
how about make advisory locks follow a similar methodology?

rough draft of documentation is done, except for the actual function
definitions :-)

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2006-09-19 16:24:49 Re: Getting rid of cmin and cmax
Previous Message Tom Lane 2006-09-19 16:20:27 Re: Vacuum error on database postgres