From 030746e78c5cdd542843aaba90b73508b5996572 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.b.smith@fujitsu.com>
Date: Tue, 20 Jun 2023 17:09:39 +1000
Subject: [PATCH v2] doc: Clarify behavior of triggers/rules in a logical
 subscriber

By default, triggers and rules do not fire on a logical replication
subscriber based on the "session_replication_role" GUC being set to
"replica". However, the docs in the logical replication section assumed
that the reader understood how this GUC worked. This modifies the docs to
be more explicit, and link back to the GUC itself.
---
 doc/src/sgml/logical-replication.sgml | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 59cf92e..aeab396 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1654,9 +1654,13 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
 
   <para>
    The apply process on the subscriber database always runs with
-   <varname>session_replication_role</varname> set
-   to <literal>replica</literal>, which produces the usual effects on triggers
-   and constraints.
+   <link linkend="guc-session-replication-role"><varname>session_replication_role</varname></link>
+   set to <literal>replica</literal>. This means that, by default,
+   triggers and rules will not fire on a subscriber. Users can optionally choose to
+   enable triggers and rules on a table using the
+   <link linkend="sql-altertable"><command>ALTER TABLE</command></link> command
+   and the <literal>ENABLE TRIGGER</literal> and <literal>ENABLE RULE</literal>
+   clauses.
   </para>
 
   <para>
-- 
1.8.3.1