From 1e11faf741174f98b4a6358f42f83a8e629aae42 Mon Sep 17 00:00:00 2001 From: dullbananas Date: Fri, 7 Jun 2024 04:42:34 -0700 Subject: [PATCH] Improve comment in triggers.sql (#4789) * Clarified existing info * Added prohibition of inconsistent update order --- .../db_schema/replaceable_schema/triggers.sql | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/crates/db_schema/replaceable_schema/triggers.sql b/crates/db_schema/replaceable_schema/triggers.sql index fa5b01018..98af3e546 100644 --- a/crates/db_schema/replaceable_schema/triggers.sql +++ b/crates/db_schema/replaceable_schema/triggers.sql @@ -5,12 +5,17 @@ -- (even if only other columns are updated) because triggers can run after the deletion of referenced rows and -- before the automatic deletion of the row that references it. This is not a problem for insert or delete. -- --- After a row update begins, a concurrent update on the same row can't begin until the whole --- transaction that contains the first update is finished. To reduce this locking, statements in --- triggers should be ordered based on the likelihood of concurrent writers. For example, updating --- site_aggregates should be done last because the same row is updated for all local stuff. If --- it were not last, then the locking period for concurrent writers would extend to include the --- time consumed by statements that come after. +-- Triggers that update multiple tables should use this order: person_aggregates, comment_aggregates, +-- post_aggregates, community_aggregates, site_aggregates +-- * The order matters because the updated rows are locked until the end of the transaction, and statements +-- in a trigger don't use separate transactions. This means that updates closer to the beginning cause +-- longer locks because the duration of each update extends the durations of the locks caused by previous +-- updates. Long locks are worse on rows that have more concurrent transactions trying to update them. The +-- listed order starts with tables that are less likely to have such rows. +-- https://www.postgresql.org/docs/16/transaction-iso.html#XACT-READ-COMMITTED +-- * Using the same order in every trigger matters because a deadlock is possible if multiple transactions +-- update the same rows in a different order. +-- https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-DEADLOCKS -- -- -- Create triggers for both post and comments