From: Vladimir Davydov <vdavydov.dev@gmail.com> To: Konstantin Osipov <kostja@tarantool.org> Cc: tarantool-patches@freelists.org Subject: Re: [PATCH 02/10] ddl: synchronize user cache with actual data state Date: Wed, 3 Jul 2019 23:00:32 +0300 [thread overview] Message-ID: <20190703200032.hlbegritnbzbobdn@esperanza> (raw) In-Reply-To: <20190703194322.GJ17318@atlas> On Wed, Jul 03, 2019 at 10:43:22PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov <vdavydov.dev@gmail.com> [19/07/03 22:34]: > > To implement transactional DDL, we must make sure that in-memory schema > > is updated synchronously with system space updates, i.e. on_replace, not > > on_commit. > > > > See also commit 22bedebe715c ("ddl: synchronize privileges cache with > > actual data state"). > > Here's a problem with replacing before commit: > > Imagine you have a yielding transaction, which is in progress. > > You replace state in the metadata cache, it doesn't matter what > cache - user, view, space, trigger, or whatever. > > Then you yield on DDL. If we yield from a DDL transaction, we must invoke on_rollback triggers immediately. I don't see any problem with that. If we don't do that now, I'll change that soon enough. > > The yielding transaction kicks-in and does some work, seeing the > dirty state. But doesn't commit yet. If on_rollback triggers are run right upon a yield, nobody will see a dirty state. > > Then you roll back. > > Your yielding transaction isolation is violated. > > Despite this gap I think we should proceed along this path. But we > also need to make sure all caches are multi-versioned: when you > replace a value in the cache, only a new transaction should see > the new value, the old one shouldn't. > > This looks fairly straightforward to implement, by adding a > schema_version to each cacheable schema object and adding > schema_version to struct txn as well. > > Now that we have killed implicit transaction start and separated > txn from fiber, we can start txn whenever we want and assign it a > schema version. > > So the patch is basically LGTM, but please be aware that moving > the changes in the cache from on_commit to on_replace breaks > yielding transaction isolation. > > I just asked myself, why did I do it this way in the first place, > and recalled the above argument.
next prev parent reply other threads:[~2019-07-03 20:00 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-03 19:30 [PATCH 00/10] Prepare box/alter.cc for transactional DDL Vladimir Davydov 2019-07-03 19:30 ` [PATCH 01/10] ddl: unreference view on space drop synchronously Vladimir Davydov 2019-07-03 19:37 ` Konstantin Osipov 2019-07-03 19:30 ` [PATCH 02/10] ddl: synchronize user cache with actual data state Vladimir Davydov 2019-07-03 19:43 ` Konstantin Osipov 2019-07-03 20:00 ` Vladimir Davydov [this message] 2019-07-04 7:42 ` [tarantool-patches] " Konstantin Osipov 2019-07-03 19:30 ` [PATCH 03/10] ddl: synchronize func " Vladimir Davydov 2019-07-04 8:12 ` Konstantin Osipov 2019-07-03 19:30 ` [PATCH 04/10] ddl: synchronize sequence " Vladimir Davydov 2019-07-04 8:16 ` Konstantin Osipov 2019-07-03 19:30 ` [PATCH 05/10] ddl: fix _space_sequence rollback Vladimir Davydov 2019-07-03 19:30 ` [PATCH 06/10] ddl: restore sequence value if drop is rolled back Vladimir Davydov 2019-07-03 19:30 ` [PATCH 07/10] ddl: don't use txn_last_stmt on _collation commit/rollback Vladimir Davydov 2019-07-03 19:30 ` [PATCH 08/10] ddl: don't use txn_last_stmt on _trigger commit/rollback Vladimir Davydov 2019-07-03 19:30 ` [PATCH 09/10] ddl: don't use txn_last_stmt on _ck_constraint commit/rollback Vladimir Davydov 2019-07-03 19:30 ` [PATCH 10/10] ddl: don't use txn_last_stmt on _cluster commit/rollback Vladimir Davydov 2019-07-04 15:01 ` [PATCH 00/10] Prepare box/alter.cc for transactional DDL Vladimir Davydov
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=20190703200032.hlbegritnbzbobdn@esperanza \ --to=vdavydov.dev@gmail.com \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='Re: [PATCH 02/10] ddl: synchronize user cache with actual data state' \ /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