diff options
| author | Amit Kapila | 2024-10-28 03:12:05 +0000 |
|---|---|---|
| committer | Amit Kapila | 2024-10-28 03:12:05 +0000 |
| commit | 1bf1140be87230c71d0e7b29939f7e2b3d073aa1 (patch) | |
| tree | 4e41b121692ed4371283cf9909c0504259fcad74 /doc/src | |
| parent | 6b652e6ce85a977e4ca7b8cc045cf4f3457b2d7b (diff) | |
Change the default value of the streaming option to 'parallel'.
Previously the default value of streaming option for a subscription was
'off'. The parallel option indicates that the changes in large
transactions (greater than logical_decoding_work_mem) are to be applied
directly via one of the parallel apply workers, if available.
The parallel mode was introduced in 16, but we refrain from enabling it by
default to avoid seeing any unpleasant behavior in the existing
applications. However we haven't found any such report yet, so this is a
good time to enable it by default.
Reported-by: Vignesh C
Author: Hayato Kuroda, Masahiko Sawada, Peter Smith, Amit Kapila
Discussion: https://postgr.es/m/CALDaNm1=MedhW23NuoePJTmonwsMSp80ddsw+sEJs0GUMC_kqQ@mail.gmail.com
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/ref/create_subscription.sgml | 27 |
1 files changed, 17 insertions, 10 deletions
diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml index 8a3096e62b5..6cf7d4f9a1a 100644 --- a/doc/src/sgml/ref/create_subscription.sgml +++ b/doc/src/sgml/ref/create_subscription.sgml @@ -271,11 +271,23 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl <listitem> <para> Specifies whether to enable streaming of in-progress transactions - for this subscription. The default value is <literal>off</literal>, - meaning all transactions are fully decoded on the publisher and only - then sent to the subscriber as a whole. + for this subscription. The default value is <literal>parallel</literal>, + meaning incoming changes are directly applied via one of the parallel + apply workers, if available. If no parallel apply worker is free to + handle streaming transactions then the changes are written to + temporary files and applied after the transaction is committed. Note + that if an error happens in a parallel apply worker, the finish LSN + of the remote transaction might not be reported in the server log. </para> + <caution> + <para> + There is a risk of deadlock when the schemas of the publisher and + subscriber differ, although such cases are rare. The apply worker + is equipped to retry these transactions automatically. + </para> + </caution> + <para> If set to <literal>on</literal>, the incoming changes are written to temporary files and then applied only after the transaction is @@ -283,13 +295,8 @@ CREATE SUBSCRIPTION <replaceable class="parameter">subscription_name</replaceabl </para> <para> - If set to <literal>parallel</literal>, incoming changes are directly - applied via one of the parallel apply workers, if available. If no - parallel apply worker is free to handle streaming transactions then - the changes are written to temporary files and applied after the - transaction is committed. Note that if an error happens in a - parallel apply worker, the finish LSN of the remote transaction - might not be reported in the server log. + If set to <literal>off</literal>, all transactions are fully decoded + on the publisher and only then sent to the subscriber as a whole. </para> </listitem> </varlistentry> |