Thread: Re: advisory locks (was: 8.2 beta blockers)
On 9/17/06, Tom Lane <tgl@sss.pgh.pa.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). merlin
"Merlin Moncure" <mmoncure@gmail.com> writes: > two questions: do we need both a shared and unshared variant of > advisory_unlock (im guessing no)? Yes, because it's possible to hold both shared and exclusive lock concurrently, so you have to say which you're releasing. > 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). Huh? regards, tom lane
On 9/19/06, Merlin Moncure <mmoncure@gmail.com> wrote: > On 9/17/06, Tom Lane <tgl@sss.pgh.pa.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
"Merlin Moncure" <mmoncure@gmail.com> writes: > 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? I think *you* are confused about lockmode vs waitmode, but the patch is not. The functions are Name | Result data type | Argument data types | Descriptionpg_advisory_lock | void | bigint | obtain exclusive advisory lockpg_advisory_lock_shared | void | bigint | obtain shared advisory lockpg_try_advisory_lock | boolean | bigint | obtain exclusive advisory lock if availablepg_try_advisory_lock_shared | boolean | bigint | obtain shared advisory lock if availablepg_advisory_unlock | boolean | bigint |release exclusive advisory lockpg_advisory_unlock_shared | boolean | bigint | release shared advisorylock These also come in flavors taking 2 int4s, which is just a different way of representing the locked object's identity, it's not different as far as lock modes go. And there's pg_advisory_unlock_all | void | | release all advisory locks which comes in just one flavor. I don't particularly care about "pg_try_advisory_lock" vs "pg_advisory_lock_nowait", but it's not entirely obvious which modifier to put first if we put them both on the end, ie is it "pg_advisory_lock_shared_nowait" or "pg_advisory_lock_nowait_shared"? Possibly the names are easier to remember as they are. regards, tom lane
On 9/19/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Merlin Moncure" <mmoncure@gmail.com> writes: > > 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? > > I think *you* are confused about lockmode vs waitmode, but the patch is > not. The functions are yep. i realized that after i sent the mail. brain fart...on reflection lets go with the try variant, its shorter. merlin