# HG changeset patch
# User jbe
# Date 1348519646 -7200
# Node ID bcfde30040f699031749b508c270fc151e1ba63a
# Parent  69d6fba0f84cbb9f3d591f40147a67433ee0ef0a
Use SHARE MODE table locks in function "lock_issue"("issue"."id") for tables neither referenced nor changed

diff -r 69d6fba0f84c -r bcfde30040f6 core.sql
--- a/core.sql	Thu Sep 13 17:02:22 2012 +0200
+++ b/core.sql	Mon Sep 24 22:47:26 2012 +0200
@@ -2925,10 +2925,9 @@
   RETURNS VOID
   LANGUAGE 'plpgsql' VOLATILE AS $$
     BEGIN
-      LOCK TABLE "member"     IN EXCLUSIVE MODE;
-      LOCK TABLE "privilege"  IN EXCLUSIVE MODE;
-      LOCK TABLE "membership" IN EXCLUSIVE MODE;
-      LOCK TABLE "policy"     IN EXCLUSIVE MODE;
+      -- The following locking order is used:
+      -- 1st) row-level lock on the issue
+      -- 2nd) table-level locks in order of occurrence in the core.sql file
       PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE;
       -- NOTE: The row-level exclusive lock in combination with the
       -- share_row_lock_issue(_via_initiative)_trigger functions (which
@@ -2936,7 +2935,11 @@
       -- is changed, which could affect calculation of snapshots or
       -- counting of votes. Table "delegation" must be table-level-locked,
       -- as it also contains issue- and global-scope delegations.
-      LOCK TABLE "delegation" IN EXCLUSIVE MODE;
+      LOCK TABLE "member"     IN EXCLUSIVE MODE;  -- exclusive avoids deadlocks
+      LOCK TABLE "privilege"  IN SHARE MODE;
+      LOCK TABLE "membership" IN SHARE MODE;
+      LOCK TABLE "policy"     IN SHARE MODE;
+      LOCK TABLE "delegation" IN SHARE MODE;
       LOCK TABLE "direct_population_snapshot"     IN EXCLUSIVE MODE;
       LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;
       LOCK TABLE "direct_interest_snapshot"       IN EXCLUSIVE MODE;