Doc: Clarify the 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 links back to the GUC itself.

Author: Jonathan Katz, Peter Smith
Reviewed-by: Vignesh C, Euler Taveira
Backpatch-through: 11
Discussion: https://postgr.es/m/5bb2c9a2-499f-e1a2-6e33-5ce96b35cc4a@postgresql.org

diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index cd277e12edeef86fcd9daa2aa1b4f6b5b20b6157..1ac374ce40c00ea3358e057f442faa179f71ebd8 100644 (file)
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -453,9 +453,13 @@
 
   <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>