pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedclarifying trigger/rule behavior on logical replication subscribers
8+ messages / 6 participants
[nested] [flat]
* clarifying trigger/rule behavior on logical replication subscribers
@ 2023-06-06 13:58 Jonathan S. Katz <jkatz@postgresql.org>
2023-06-07 10:39 ` Re: clarifying trigger/rule behavior on logical replication subscribers vignesh C <vignesh21@gmail.com>
2023-06-21 00:03 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
0 siblings, 2 replies; 8+ messages in thread
From: Jonathan S. Katz @ 2023-06-06 13:58 UTC (permalink / raw)
To: Pg Docs <pgsql-docs@lists.postgresql.org>
Hi,
While answering a question on "do triggers fire on a logical replication
subscriber by default?" I tried to look up a reference to this behavior
in the docs. There wasn't a clear reference point, but on the
architecture page[1], I found this line that was closest to the answer:
"The apply process on the subscriber database always runs with
session_replication_role set to replica, which produces the usual
effects on triggers and constraints."
which assumes that the reader knows what the "usual effects" are.
Attached is a patch that disambiguates this.
Two additional items:
1. I do think this should be backpatched because it clarifies an
existing behavior.
2. I don't know if we want to add a note about the trigger/rule behavior
elsewhere in the logical replication section. I don't know if a reader
would be expecting to find this in the "architecture" section.
Thanks,
Jonathan
[1]
https://www.postgresql.org/docs/devel/logical-replication-architecture.html
From 23aaa7fe401d85736ebf426626b063075a75c918 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Tue, 6 Jun 2023 09:51:32 -0400
Subject: [PATCH] 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 59cf92e6a9..b18cff73ed 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 replica. 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>
--
2.37.1 (Apple Git-137.1)
Attachments:
[text/plain] v1-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-.patch (1.7K, ../../5bb2c9a2-499f-e1a2-6e33-5ce96b35cc4a@postgresql.org/2-v1-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-.patch)
download | inline diff:
From 23aaa7fe401d85736ebf426626b063075a75c918 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Tue, 6 Jun 2023 09:51:32 -0400
Subject: [PATCH] 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 59cf92e6a9..b18cff73ed 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 replica. 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>
--
2.37.1 (Apple Git-137.1)
[application/pgp-signature] OpenPGP_signature (839B, ../../5bb2c9a2-499f-e1a2-6e33-5ce96b35cc4a@postgresql.org/3-OpenPGP_signature)
download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
@ 2023-06-07 10:39 ` vignesh C <vignesh21@gmail.com>
2023-06-08 06:36 ` Re: clarifying trigger/rule behavior on logical replication subscribers Amit Kapila <amit.kapila16@gmail.com>
1 sibling, 1 reply; 8+ messages in thread
From: vignesh C @ 2023-06-07 10:39 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; Amit Kapila <amit.kapila16@gmail.com>; +Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
On Wed, 7 Jun 2023 at 10:17, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> Hi,
>
> While answering a question on "do triggers fire on a logical replication
> subscriber by default?" I tried to look up a reference to this behavior
> in the docs. There wasn't a clear reference point, but on the
> architecture page[1], I found this line that was closest to the answer:
>
> "The apply process on the subscriber database always runs with
> session_replication_role set to replica, which produces the usual
> effects on triggers and constraints."
>
> which assumes that the reader knows what the "usual effects" are.
>
> Attached is a patch that disambiguates this.
>
Thanks for the patch, one small change required, "literal>" should be
"<literal>":
+ 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>
Regards,
Vignesh
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
2023-06-07 10:39 ` Re: clarifying trigger/rule behavior on logical replication subscribers vignesh C <vignesh21@gmail.com>
@ 2023-06-08 06:36 ` Amit Kapila <amit.kapila16@gmail.com>
2023-06-08 15:15 ` Re: clarifying trigger/rule behavior on logical replication subscribers Euler Taveira <euler@eulerto.com>
0 siblings, 1 reply; 8+ messages in thread
From: Amit Kapila @ 2023-06-08 06:36 UTC (permalink / raw)
To: vignesh C <vignesh21@gmail.com>; +Cc: Jonathan S. Katz <jkatz@postgresql.org>; Pg Docs <pgsql-docs@lists.postgresql.org>
On Wed, Jun 7, 2023 at 4:09 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Wed, 7 Jun 2023 at 10:17, Jonathan S. Katz <jkatz@postgresql.org> wrote:
> >
> > Hi,
> >
> > While answering a question on "do triggers fire on a logical replication
> > subscriber by default?" I tried to look up a reference to this behavior
> > in the docs. There wasn't a clear reference point, but on the
> > architecture page[1], I found this line that was closest to the answer:
> >
> > "The apply process on the subscriber database always runs with
> > session_replication_role set to replica, which produces the usual
> > effects on triggers and constraints."
> >
> > which assumes that the reader knows what the "usual effects" are.
> >
> > Attached is a patch that disambiguates this.
> >
I agree that it is a good idea to be explicit about this behavior. As
mentioned by you, it would be better to backpatch this. Also, I
thought about moving this to some other section like [1] but I think
we need to explain a bit about apply worker before providing this
specific information. So, the current place seems to be the best bet
considering the way current logical replication is documented.
[1] - https://www.postgresql.org/docs/devel/logical-replication-subscription.html
--
With Regards,
Amit Kapila.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
2023-06-07 10:39 ` Re: clarifying trigger/rule behavior on logical replication subscribers vignesh C <vignesh21@gmail.com>
2023-06-08 06:36 ` Re: clarifying trigger/rule behavior on logical replication subscribers Amit Kapila <amit.kapila16@gmail.com>
@ 2023-06-08 15:15 ` Euler Taveira <euler@eulerto.com>
0 siblings, 0 replies; 8+ messages in thread
From: Euler Taveira @ 2023-06-08 15:15 UTC (permalink / raw)
To: pgsql-docs@lists.postgresql.org
On Thu, Jun 8, 2023, at 3:36 AM, Amit Kapila wrote:
> I agree that it is a good idea to be explicit about this behavior. As
> mentioned by you, it would be better to backpatch this. Also, I
> thought about moving this to some other section like [1] but I think
> we need to explain a bit about apply worker before providing this
> specific information. So, the current place seems to be the best bet
> considering the way current logical replication is documented.
I agree with this clarification in the suggested section. One small suggestion
is to avoid the word "replica", AFAICS it is not used in the logical
replication chapter; use "subscriber" instead. Another suggestion is to add
links to the exact ALTER TABLE ... ENABLE TRIGGER and ALTER TABLE ... ENABLE
RULE since we recently added it.
--
Euler Taveira
EDB https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
@ 2023-06-21 00:03 ` Peter Smith <smithpb2250@gmail.com>
2023-07-27 02:16 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
1 sibling, 1 reply; 8+ messages in thread
From: Peter Smith @ 2023-06-21 00:03 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
Hi.
I have made a patch v2.
This addresses the following:
- [1] Vignesh's review comment about unclosed SGML literal tag.
- [2] Euler's review comment about the word "replica"
But I did not address Euler's other review suggestion [2] about giving
direct links, because actually this patch text (without any direct
links) is almost identical with the existing
"session_replication_role" docs [3]. Instead of making the scope of
this patch bigger, if direct links are really wanted, I thought it is
better to have a separate patch for that which can address both docs.
~~~
I also tested/attached back-patches of the v2 patch for earlier
PostgreSQL versions. Actually, it turns out all the patches are the
same -- just named differently.
------
[1] https://www.postgresql.org/message-id/CALDaNm1fAaeOhdTts3LgXs_e1TPZke3-HqFA9b8ZjVXOM66H5Q%40mail.gma...
[2] https://www.postgresql.org/message-id/288747bd-911b-4370-8db2-6ecbb096037e%40app.fastmail.com
[3] https://www.postgresql.org/docs/devel/runtime-config-client.html
Kind Regards,
Peter Smith.
Fujitsu Australia
Attachments:
[application/octet-stream] v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_13.patch (1.7K, ../../CAHut+PvQuiM01wqo-WXTKmZFDCM7bb4ttXkNU1XhY48b2RTY5Q@mail.gmail.com/2-v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_13.patch)
download | inline diff:
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
[application/octet-stream] v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_11.patch (1.7K, ../../CAHut+PvQuiM01wqo-WXTKmZFDCM7bb4ttXkNU1XhY48b2RTY5Q@mail.gmail.com/3-v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_11.patch)
download | inline diff:
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
[application/octet-stream] v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_12.patch (1.7K, ../../CAHut+PvQuiM01wqo-WXTKmZFDCM7bb4ttXkNU1XhY48b2RTY5Q@mail.gmail.com/4-v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_12.patch)
download | inline diff:
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
[application/octet-stream] v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_14.patch (1.7K, ../../CAHut+PvQuiM01wqo-WXTKmZFDCM7bb4ttXkNU1XhY48b2RTY5Q@mail.gmail.com/5-v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_14.patch)
download | inline diff:
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
[application/octet-stream] v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-HEAD.patch (1.7K, ../../CAHut+PvQuiM01wqo-WXTKmZFDCM7bb4ttXkNU1XhY48b2RTY5Q@mail.gmail.com/6-v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-HEAD.patch)
download | inline diff:
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
[application/octet-stream] v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_15.patch (1.7K, ../../CAHut+PvQuiM01wqo-WXTKmZFDCM7bb4ttXkNU1XhY48b2RTY5Q@mail.gmail.com/7-v2-0001-doc-Clarify-behavior-of-triggers-rules-in-a-logical-subscriber-REL_15.patch)
download | inline diff:
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
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
2023-06-21 00:03 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
@ 2023-07-27 02:16 ` Peter Smith <smithpb2250@gmail.com>
2023-07-27 05:28 ` Re: clarifying trigger/rule behavior on logical replication subscribers Laurenz Albe <laurenz.albe@cybertec.at>
2023-07-27 08:40 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
0 siblings, 2 replies; 8+ messages in thread
From: Peter Smith @ 2023-07-27 02:16 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
I created patches for this over a month ago, but then the thread went
quiet. Is there something more needed, or was it just accidentally
overlooked?
Should this be added to the commitfest?
------
Kind Regards,
Peter Smith.
Fujitsu Australia.
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
2023-06-21 00:03 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
2023-07-27 02:16 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
@ 2023-07-27 05:28 ` Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 0 replies; 8+ messages in thread
From: Laurenz Albe @ 2023-07-27 05:28 UTC (permalink / raw)
To: Peter Smith <smithpb2250@gmail.com>; Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
On Thu, 2023-07-27 at 12:16 +1000, Peter Smith wrote:
> I created patches for this over a month ago, but then the thread went
> quiet. Is there something more needed, or was it just accidentally
> overlooked?
>
> Should this be added to the commitfest?
Yes, please add it to the commitfest. That increases the likelyhood of
you patch not being forgotten.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: clarifying trigger/rule behavior on logical replication subscribers
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
2023-06-21 00:03 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
2023-07-27 02:16 ` Re: clarifying trigger/rule behavior on logical replication subscribers Peter Smith <smithpb2250@gmail.com>
@ 2023-07-27 08:40 ` Peter Smith <smithpb2250@gmail.com>
1 sibling, 0 replies; 8+ messages in thread
From: Peter Smith @ 2023-07-27 08:40 UTC (permalink / raw)
To: Jonathan S. Katz <jkatz@postgresql.org>; +Cc: Pg Docs <pgsql-docs@lists.postgresql.org>
It seems this was pushed already [1]. Sorry for the false alarm.
------
[1] https://github.com/postgres/postgres/commit/f5c446e3367527f9db1506d7c38d2f56e20950b6
Kind Regards,
Peter Smith.
Fujitsu Australia.
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2023-07-27 08:40 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-06 13:58 clarifying trigger/rule behavior on logical replication subscribers Jonathan S. Katz <jkatz@postgresql.org>
2023-06-07 10:39 ` vignesh C <vignesh21@gmail.com>
2023-06-08 06:36 ` Amit Kapila <amit.kapila16@gmail.com>
2023-06-08 15:15 ` Euler Taveira <euler@eulerto.com>
2023-06-21 00:03 ` Peter Smith <smithpb2250@gmail.com>
2023-07-27 02:16 ` Peter Smith <smithpb2250@gmail.com>
2023-07-27 05:28 ` Laurenz Albe <laurenz.albe@cybertec.at>
2023-07-27 08:40 ` Peter Smith <smithpb2250@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox