liquid_feedback_core
diff core.sql @ 297:779ba19a07df
Different locking levels and different locking order in function "lock_issue"("issue"."id") to avoid deadlocks
(includes update of update/core-update.v2.0.11-v2.1.0.sql)
(includes update of update/core-update.v2.0.11-v2.1.0.sql)
author | jbe |
---|---|
date | Tue Sep 25 02:32:51 2012 +0200 (2012-09-25) |
parents | 9ab561a91035 bcfde30040f6 |
children | dbd237d86a8a |
line diff
1.1 --- a/core.sql Sun Aug 26 21:04:20 2012 +0200 1.2 +++ b/core.sql Tue Sep 25 02:32:51 2012 +0200 1.3 @@ -2989,10 +2989,9 @@ 1.4 RETURNS VOID 1.5 LANGUAGE 'plpgsql' VOLATILE AS $$ 1.6 BEGIN 1.7 - LOCK TABLE "member" IN SHARE MODE; 1.8 - LOCK TABLE "privilege" IN SHARE MODE; 1.9 - LOCK TABLE "membership" IN SHARE MODE; 1.10 - LOCK TABLE "policy" IN SHARE 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 @@ -3000,6 +2999,10 @@ 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 "member" IN EXCLUSIVE MODE; -- exclusive avoids deadlocks 1.22 + LOCK TABLE "privilege" IN SHARE MODE; 1.23 + LOCK TABLE "membership" IN SHARE MODE; 1.24 + LOCK TABLE "policy" IN SHARE MODE; 1.25 LOCK TABLE "delegation" IN SHARE MODE; 1.26 LOCK TABLE "direct_population_snapshot" IN EXCLUSIVE MODE; 1.27 LOCK TABLE "delegating_population_snapshot" IN EXCLUSIVE MODE;