"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