Remove duplicated comment block in event_trigger.c
authorMichael Paquier <michael@paquier.xyz>
Thu, 14 May 2020 23:19:30 +0000 (08:19 +0900)
committerMichael Paquier <michael@paquier.xyz>
Thu, 14 May 2020 23:19:30 +0000 (08:19 +0900)
The reasons why event triggers are disabled in standalone mode are
documented in the code path of ddl_command_start, and other places
checking if standalone mode is enabled or not mention to refer to the
comment for ddl_command_start, except for table_rewrite that duplicated
the same explanation.

Reported-by: David G. Johnston
Discussion: https://postgr.es/m/CAKFQuwYqHtXpvr2mBJRwH9f+Y5y1GXw3rhbaAu0Dk2MoNevsmA@mail.gmail.com

src/backend/commands/event_trigger.c

index 918b9b4d8fa21ab8362a8140571bdec59a53c13a..02ab40eaac757a15868fc05a3a99b9d4a0e6da6f 100644 (file)
@@ -833,20 +833,8 @@ EventTriggerTableRewrite(Node *parsetree, Oid tableOid, int reason)
    EventTriggerData trigdata;
 
    /*
-    * Event Triggers are completely disabled in standalone mode.  There are
-    * (at least) two reasons for this:
-    *
-    * 1. A sufficiently broken event trigger might not only render the
-    * database unusable, but prevent disabling itself to fix the situation.
-    * In this scenario, restarting in standalone mode provides an escape
-    * hatch.
-    *
-    * 2. BuildEventTriggerCache relies on systable_beginscan_ordered, and
-    * therefore will malfunction if pg_event_trigger's indexes are damaged.
-    * To allow recovery from a damaged index, we need some operating mode
-    * wherein event triggers are disabled.  (Or we could implement
-    * heapscan-and-sort logic for that case, but having disaster recovery
-    * scenarios depend on code that's otherwise untested isn't appetizing.)
+    * See EventTriggerDDLCommandStart for a discussion about why event
+    * triggers are disabled in single user mode.
     */
    if (!IsUnderPostmaster)
        return;