From: Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Cyrill Gorcunov <gorcunov@gmail.com>, tml <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v14 0/6] qsync: implement packets filtering Date: Sun, 12 Sep 2021 17:43:48 +0200 [thread overview] Message-ID: <ca244699-8fa2-b871-21ae-029e5db260a4@tarantool.org> (raw) In-Reply-To: <20210910152910.607398-1-gorcunov@gmail.com> Hi! Thanks for the fixes! On 10.09.2021 17:29, Cyrill Gorcunov via Tarantool-patches wrote: > Guys, take a look please, once time permit. The questionable moments: > > - use filter disabling procedure for join/recovery: we make it so since > snapshot has promote record which fills initial limbo state I still don't understand why do you need the disabling. Before the snapshot is recovered, the limbo is empty and not owner by anybody. It is fully valid and working, like if DEMOTE is called. Correct? Snapshot's promote should make it belong to the owner persisted in promote. Also correct? The next rows just replay already applied data. Also correct? It managed to apply first time and must manage to do so again. Agree? In what of these statements I miss a mistake which makes you disable the filtering? > - need more tests to cover all possible scenarios > > - I keep filter_confirm_rollback() as is but rereading Vlad's comment > > > > 9. What if rollback is for LSN > limbo's last LSN? It > > also means nothing to do. The same for confirm LSN < limbo's > > first LSN. > > > I presume I need to traverse limbo and test if incoming LSN is > present inside current queue. It should be enough to know the LSN range in there AFAIU. Additionally, I tried the test from the ticket again. It still does not behave as expected. I remind, on the last review I also tried: On top of the branch I tried the test I pasted in the ticket's description. I see the connection now breaks in one direction. But the new leader still follows the old leader somewhy. And you said: I'll take more precise look, thanks! https://lists.tarantool.org/tarantool-patches/YRBUww6p1dUNL0mx@grain/ So what are the news on that? The new leader should not follow the old one. If anything, even the vice-versa situation would be fine I suppose - the old one following the new one. But the current way does not look valid. The old leader could send all kinds of irrelevant garbage and the new leader would happily swallow it. The same happens in this test (on top of the last commit of this patchset): https://github.com/tarantool/tarantool/issues/5295#issuecomment-912106680 The new leader still replicates from the old broken one.
prev parent reply other threads:[~2021-09-12 15:43 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-10 15:29 Cyrill Gorcunov via Tarantool-patches 2021-09-10 15:29 ` [Tarantool-patches] [PATCH v14 1/6] qsync: track confirmed lsn number on reads Cyrill Gorcunov via Tarantool-patches 2021-09-12 15:44 ` Vladislav Shpilevoy via Tarantool-patches 2021-09-12 22:18 ` Cyrill Gorcunov via Tarantool-patches 2021-09-13 8:33 ` Serge Petrenko via Tarantool-patches 2021-09-13 8:50 ` Serge Petrenko via Tarantool-patches 2021-09-10 15:29 ` [Tarantool-patches] [PATCH v14 2/6] qsync: update confirmed lsn on initial promote request Cyrill Gorcunov via Tarantool-patches 2021-09-12 15:44 ` Vladislav Shpilevoy via Tarantool-patches 2021-09-12 22:25 ` Cyrill Gorcunov via Tarantool-patches 2021-09-13 8:52 ` Serge Petrenko via Tarantool-patches 2021-09-13 14:20 ` [Tarantool-patches] [RFC] qsync: overall design Cyrill Gorcunov via Tarantool-patches 2021-09-10 15:29 ` [Tarantool-patches] [PATCH v14 3/6] latch: add latch_is_locked helper Cyrill Gorcunov via Tarantool-patches 2021-09-10 15:29 ` [Tarantool-patches] [PATCH v14 4/6] qsync: order access to the limbo terms Cyrill Gorcunov via Tarantool-patches 2021-09-12 15:44 ` Vladislav Shpilevoy via Tarantool-patches 2021-09-13 10:52 ` Cyrill Gorcunov via Tarantool-patches 2021-09-10 15:29 ` [Tarantool-patches] [PATCH v14 5/6] qsync: filter incoming synchro requests Cyrill Gorcunov via Tarantool-patches 2021-09-12 15:44 ` Vladislav Shpilevoy via Tarantool-patches 2021-09-14 19:41 ` Cyrill Gorcunov via Tarantool-patches 2021-09-10 15:29 ` [Tarantool-patches] [PATCH v14 6/6] test: add replication/gh-6036-rollback-confirm Cyrill Gorcunov via Tarantool-patches 2021-09-12 15:44 ` Vladislav Shpilevoy via Tarantool-patches 2021-09-12 15:43 ` 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=ca244699-8fa2-b871-21ae-029e5db260a4@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=gorcunov@gmail.com \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v14 0/6] qsync: implement packets filtering' \ /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