Re: Skipping logical replication transactions on subscriber side
Amit Kapila <amit.kapila16@gmail.com>
On Tue, Mar 1, 2022 at 8:31 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> I've attached an updated patch along with two patches for cfbot tests
> since the main patch (0003) depends on the other two patches. Both
> 0001 and 0002 patches are the same ones I attached on another
> thread[2].
>
Few comments on 0003:
=====================
1.
+ <row>
+ <entry role="catalog_table_entry"><para role="column_definition">
+ <structfield>subskiplsn</structfield> <type>pg_lsn</type>
+ </para>
+ <para>
+ Commit LSN of the transaction whose changes are to be skipped,
if a valid
+ LSN; otherwise <literal>0/0</literal>.
+ </para></entry>
+ </row>
Can't this be prepared LSN or rollback prepared LSN? Can we say
Finish/End LSN and then add some details which all LSNs can be there?
2. The conflict resolution explanation needs an update after the
latest commits and we should probably change the commit LSN
terminology as mentioned in the previous point.
3. The text in alter_subscription.sgml looks a bit repetitive to me
(similar to what we have in logical-replication.sgml related to
conflicts). Here also we refer to only commit LSN which needs to be
changed as mentioned in the previous two points.
4.
if (strcmp(lsn_str, "none") == 0)
+ {
+ /* Setting lsn = NONE is treated as resetting LSN */
+ lsn = InvalidXLogRecPtr;
+ }
+ else
+ {
+ /* Parse the argument as LSN */
+ lsn = DatumGetTransactionId(DirectFunctionCall1(pg_lsn_in,
+ CStringGetDatum(lsn_str)));
+
+ if (XLogRecPtrIsInvalid(lsn))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("invalid WAL location (LSN): %s", lsn_str)));
Is there a reason that we don't want to allow setting 0
(InvalidXLogRecPtr) for skip LSN?
5.
+# The subscriber will enter an infinite error loop, so we don't want
+# to overflow the server log with error messages.
+$node_subscriber->append_conf(
+ 'postgresql.conf',
+ qq[
+wal_retrieve_retry_interval = 2s
+]);
Can we change this test to use disable_on_error feature? I am thinking
if the disable_on_error feature got committed first, maybe we can have
one test file for this and disable_on_error feature (something like
conflicts.pl).
--
With Regards,
Amit Kapila.
Commits
-
Test ALIGNOF_DOUBLE==4 compatibility under ALIGNOF_DOUBLE==8.
- c1da0acbb06e 15.0 landed
-
Reorder subskiplsn in pg_subscription to avoid alignment issues.
- 79b716cfb7a1 15.0 landed
-
Add ALTER SUBSCRIPTION ... SKIP.
- 208c5d65bbd6 15.0 landed
-
Optionally disable subscriptions on error.
- 705e20f8550c 15.0 cited
-
Update docs of logical replication for commit 8d74fc96db.
- 85c61ba8920b 15.0 landed
-
Respect permissions within logical replication.
- a2ab9c06ea15 15.0 cited
-
Fix regression test failure caused by commit 8d74fc96db.
- 41e66fee0516 15.0 landed
-
Add a view to show the stats of subscription workers.
- 8d74fc96db5f 15.0 landed
-
Add logical change details to logical replication worker errcontext.
- abc0910e2e0a 15.0 landed
-
Rename LOGICAL_REP_MSG_STREAM_END to LOGICAL_REP_MSG_STREAM_STOP.
- 4cd7a1896871 15.0 landed
-
Fix typo in protocol.sgml.
- e1915646658d 14.0 landed
- 0ac1aee0d7d8 15.0 landed
-
Remove unused argument in apply_handle_commit_internal().
- f4b939f1a372 14.0 landed
- 16bd4becee32 15.0 landed
-
Fix replication of in-progress transactions in tablesync worker.
- 0926e96c4934 14.0 cited
-
Reorder pg_sequence columns to avoid alignment issue
- f3b421da5f4a 10.0 cited