Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers
From | Amit Kapila |
---|---|
Subject | Re: Skipping logical replication transactions on subscriber side |
Date | |
Msg-id | CAA4eK1LK6tOuqON3HtVGU7THyX82awJA16CO_gKyrQ80haQ6ng@mail.gmail.com Whole thread Raw |
In response to | Re: Skipping logical replication transactions on subscriber side (Masahiko Sawada <sawada.mshk@gmail.com>) |
Responses |
Re: Skipping logical replication transactions on subscriber side
Re: Skipping logical replication transactions on subscriber side |
List | pgsql-hackers |
On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > I've attached an updated version patch. > Review: ======= 1. +++ b/doc/src/sgml/logical-replication.sgml @@ -366,15 +366,19 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER transaction, the subscription needs to be disabled temporarily by <command>ALTER SUBSCRIPTION ... DISABLE</command> first or alternatively, the subscription can be used with the <literal>disable_on_error</literal> option. - Then, the transaction can be skipped by calling the + Then, the transaction can be skipped by using + <command>ALTER SUBSCRITPION ... SKIP</command> with the finish LSN + (i.e., LSN 0/14C0378). After that the replication + can be resumed by <command>ALTER SUBSCRIPTION ... ENABLE</command>. + Alternatively, the transaction can also be skipped by calling the Do we really need to disable the subscription for the skip feature? I think that is required for origin_advance. Also, probably, we can say Finish LSN could be Prepare LSN, Commit LSN, etc. 2. + /* + * Quick return if it's not requested to skip this transaction. This + * function is called every start of applying changes and we assume that + * skipping the transaction is not used in many cases. + */ + if (likely(XLogRecPtrIsInvalid(MySubscription->skiplsn) || The second part of this comment (especially ".. every start of applying changes ..") sounds slightly odd to me. How about changing it to: "This function is called for every remote transaction and we assume that skipping the transaction is not used in many cases." 3. + + ereport(LOG, + errmsg("start skipping logical replication transaction which finished at %X/%X", ... + ereport(LOG, + (errmsg("done skipping logical replication transaction which finished at %X/%X", No need of 'which' in above LOG messages. I think the message will be clear without the use of which in above message. 4. + ereport(LOG, + (errmsg("done skipping logical replication transaction which finished at %X/%X", + LSN_FORMAT_ARGS(skip_xact_finish_lsn)))); + + /* Stop skipping changes */ + skip_xact_finish_lsn = InvalidXLogRecPtr; Let's reverse the order of these statements to make them consistent with the corresponding maybe_start_* function. 5. + + if (myskiplsn != finish_lsn) + ereport(WARNING, + errmsg("skip-LSN of logical replication subscription \"%s\" cleared", MySubscription->name), Shouldn't this be a LOG instead of a WARNING as this will be displayed only in server logs and by background apply worker? 6. @@ -1583,7 +1649,8 @@ apply_handle_insert(StringInfo s) TupleTableSlot *remoteslot; MemoryContext oldctx; - if (handle_streamed_transaction(LOGICAL_REP_MSG_INSERT, s)) + if (is_skipping_changes() || Is there a reason to keep the skip_changes check here and in other DML operations instead of at one central place in apply_dispatch? 7. + /* + * Start a new transaction to clear the subskipxid, if not started + * yet. The transaction is committed below. + */ + if (!IsTransactionState()) I think the second part of the comment: "The transaction is committed below." is not required. 8. + XLogRecPtr subskiplsn; /* All changes which finished at this LSN are + * skipped */ + #ifdef CATALOG_VARLEN /* variable-length fields start here */ /* Connection string to the publisher */ text subconninfo BKI_FORCE_NOT_NULL; @@ -109,6 +112,8 @@ typedef struct Subscription bool disableonerr; /* Indicates if the subscription should be * automatically disabled if a worker error * occurs */ + XLogRecPtr skiplsn; /* All changes which finished at this LSN are + * skipped */ No need for 'which' in the above comments. 9. Can we merge 029_disable_on_error in 030_skip_xact and name it as 029_on_error (or 029_on_error_skip_disable or some variant of it)? Both seem to be related features. I am slightly worried at the pace at which the number of test files are growing in subscription test. -- With Regards, Amit Kapila.
pgsql-hackers by date: