liquid_feedback_core
changeset 296:bcfde30040f6
Use SHARE MODE table locks in function "lock_issue"("issue"."id") for tables neither referenced nor changed
author | jbe |
---|---|
date | Mon Sep 24 22:47:26 2012 +0200 (2012-09-24) |
parents | 69d6fba0f84c |
children | 779ba19a07df fcdaa4e986b9 |
files | core.sql |
line diff
1.1 --- a/core.sql Thu Sep 13 17:02:22 2012 +0200 1.2 +++ b/core.sql Mon Sep 24 22:47:26 2012 +0200 1.3 @@ -2925,10 +2925,9 @@ 1.4 RETURNS VOID 1.5 LANGUAGE 'plpgsql' VOLATILE AS $$ 1.6 BEGIN 1.7 - LOCK TABLE "member" IN EXCLUSIVE MODE; 1.8 - LOCK TABLE "privilege" IN EXCLUSIVE MODE; 1.9 - LOCK TABLE "membership" IN EXCLUSIVE MODE; 1.10 - LOCK TABLE "policy" IN EXCLUSIVE MODE; 1.11 + -- The following locking order is used: 1.12 + -- 1st) row-level lock on the issue 1.13 + -- 2nd) table-level locks in order of occurrence in the core.sql file 1.14 PERFORM NULL FROM "issue" WHERE "id" = "issue_id_p" FOR UPDATE; 1.15 -- NOTE: The row-level exclusive lock in combination with the 1.16 -- share_row_lock_issue(_via_initiative)_trigger functions (which 1.17 @@ -2936,7 +2935,11 @@ 1.18 -- is changed, which could affect calculation of snapshots or 1.19 -- counting of votes. Table "delegation" must be table-level-locked, 1.20 -- as it also contains issue- and global-scope delegations. 1.21 - LOCK TABLE "delegation" IN EXCLUSIVE MODE; 1.22 + LOCK TABLE "member" IN EXCLUSIVE MODE; -- exclusive avoids deadlocks 1.23 + LOCK TABLE "privilege" IN SHARE MODE; 1.24 + LOCK TABLE "membership" IN SHARE MODE; 1.25 + LOCK TABLE "policy" IN SHARE MODE; 1.26 + LOCK TABLE "delegation" IN SHARE MODE; 1.27 LOCK TABLE "direct_population_snapshot" IN EXCLUSIVE MODE; 1.28 LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE; 1.29 LOCK TABLE "direct_interest_snapshot" IN EXCLUSIVE MODE;