From: Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Serge Petrenko <sergepetrenko@tarantool.org>, gorcunov@gmail.com Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH] replication: send only confirmed data during final join Date: Wed, 10 Mar 2021 20:12:25 +0100 [thread overview] Message-ID: <200dc67f-45e4-bff5-5105-eb99baca8d07@tarantool.org> (raw) In-Reply-To: <20210310134824.33794-1-sergepetrenko@tarantool.org> Hi! Thanks for the patch! See 3 comments below. > diff --git a/src/box/applier.cc b/src/box/applier.cc > index 8d7ce5d99..2af7693a0 100644 > --- a/src/box/applier.cc > +++ b/src/box/applier.cc > @@ -526,7 +528,8 @@ applier_wait_register(struct applier *applier, uint64_t row_count) > while (true) { > coio_read_xrow(coio, ibuf, &row); > applier->last_row_time = ev_monotonic_now(loop()); > - if (iproto_type_is_dml(row.type)) { > + if (iproto_type_is_dml(row.type) || > + row.type == IPROTO_CONFIRM) { > vclock_follow_xrow(&replicaset.vclock, &row); > if (apply_final_join_row(&row) != 0) 1. apply_final_join_row() internally simply ignores synchro rows. Including the rollbacks. You might want to handle synchro rows separately from apply_final_join_row(). Just follow vclock and increase row_count. apply_final_join_row() would assert that the row is DML then. 2. What if we meet ROLLBACK during final join rows retrieval? It could be stored in xlogs created during initial join. It might even be followed for CONFIRMs of newer synchro transactions. Or might now, it does not matter. Won't ROLLBACK among final join rows result into unknown request type again? > diag_raise(); > diff --git a/src/box/relay.cc b/src/box/relay.cc > index 186f77ed4..5699b8a63 100644 > --- a/src/box/relay.cc > +++ b/src/box/relay.cc > @@ -381,6 +381,10 @@ relay_final_join(int fd, uint64_t sync, struct vclock *start_vclock, > relay_delete(relay); > }); > > + /* \sa relay_initial_join(). */ 3. Probably better stick with @sa, as we usually use @ instead of \ in the new code. > + if (txn_limbo_wait_confirm(&txn_limbo) != 0) > + diag_raise(); > + > relay->r = recovery_new(wal_dir(), false, start_vclock); > vclock_copy(&relay->stop_vclock, stop_vclock);
prev parent reply other threads:[~2021-03-10 19:12 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-10 13:48 Serge Petrenko via Tarantool-patches 2021-03-10 19:12 ` Vladislav Shpilevoy via Tarantool-patches [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=200dc67f-45e4-bff5-5105-eb99baca8d07@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=sergepetrenko@tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH] replication: send only confirmed data during final join' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox