Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers
From | Masahiko Sawada |
---|---|
Subject | Re: Skipping logical replication transactions on subscriber side |
Date | |
Msg-id | CAD21AoC-0TTt7oRcBaj4zgMkQggDUb7t2ECk6KPmg+=e9SnMYg@mail.gmail.com Whole thread Raw |
In response to | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
List | pgsql-hackers |
On Tue, Mar 15, 2022 at 7:18 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Mar 15, 2022 at 11:43 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > I've attached an updated version patch. > > > > Review: > ======= Thank you for the comments. > 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. Not necessary to disable the subscription for skip feature. Fixed. > > 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." > Fixed. > 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. Removed. > > 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. But we cannot simply rever the order since skip_xact_finish_lsn is used in the log message. Do we want to use a variable for it? > > 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? WARNINGs are used also by other auxiliary processes such as archiver, autovacuum workers, and launcher. So I think we can use it here. > > 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? I'd leave it as is as I mentioned in another email. But I've added some comments as you suggested. > > 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. Removed. > > 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. Removed. > > 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. Yes, we can merge them. I'll submit an updated version patch after incorporating all comments I got. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
pgsql-hackers by date: