On Sun, Jan 16, 2011 at 06:20, Marko Tiikkaja <marko.tiikk...@cs.helsinki.fi> wrote: > Here's the latest version of the patch. It now uses the API proposed by > Simon, but still lacks documentation changes, which I'm going to send > tomorrow.
Here is a short review for Transaction scoped advisory locks: https://commitfest.postgresql.org/action/patch_view?id=518 == Features == The patch adds pg_[try_]advisory_xact_lock[_shared] functions. The function names follows the past discussion -- it's better than "bool isXact" argument or changing the existing behavior. == Coding == The patch itself is well-formed and be applied cleanly. I expect documentation will come soon. There is no regression test, but we have no regression test for advisory locks even now. Tests for lock conflict might be difficult, but we could have single-threaded test for lock/unlock and pg_locks view. == Questions == I have a question about unlocking transaction-scope advisory locks. We cannot unlock them with pg_advisory_unlock(), but can unlock with pg_advisory_unlock_all(). It's inconsistent behavior. Furthermore, I wonder we can allow unlocking transaction-scope locks -- we have LOCK TABLE but don't have UNLOCK TABLE. postgres=# BEGIN; BEGIN postgres=# SELECT pg_advisory_xact_lock(1); pg_advisory_xact_lock ----------------------- (1 row) postgres=# SELECT pg_advisory_unlock(1); WARNING: you don't own a lock of type ExclusiveLock pg_advisory_unlock -------------------- f (1 row) postgres=# SELECT pg_advisory_unlock_all(); pg_advisory_unlock_all ------------------------ (1 row) postgres=# ROLLBACK; ROLLBACK -- Itagaki Takahiro -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
