"Merlin Moncure" <[EMAIL PROTECTED]> 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 | Description pg_advisory_lock | void | bigint | obtain exclusive advisory lock pg_advisory_lock_shared | void | bigint | obtain shared advisory lock pg_try_advisory_lock | boolean | bigint | obtain exclusive advisory lock if available pg_try_advisory_lock_shared | boolean | bigint | obtain shared advisory lock if available pg_advisory_unlock | boolean | bigint | release exclusive advisory lock pg_advisory_unlock_shared | boolean | bigint | release shared advisory lock 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match