From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 30 Jul 2019 13:56:59 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 3/3] alter: fix rollback in case DDL and DML are used in the same transaction Message-ID: <20190730105659.GI4659@esperanza> References: <20190724223255.GC13150@atlas> <20190725085117.GF24631@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190725085117.GF24631@esperanza> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Thu, Jul 25, 2019 at 11:51:17AM +0300, Vladimir Davydov wrote: > On Thu, Jul 25, 2019 at 01:32:55AM +0300, Konstantin Osipov wrote: > > * Vladimir Davydov [19/07/23 18:49]: > > > A txn_stmt keeps a reference to the space it modifies. Memtx uses this > > > space reference to revert the statement on error or voluntary rollback > > > so the space must stay valid throughout the whole transaction. > > > > > > The problem is DML statements may be mixed in a DDL transaction, in > > > which case we always roll back DML statements first and only then run > > > rollback triggers to revert changes done to the schema by the DDL > > > statements. This means every DDL statement modifying the space cache > > > must be implemented in such a way that it leaves both the old space > > > and the new space valid until commit or rollback. > > > > How are we going to enforce this invariant by code structure going > > forward other than patching it hastily when it breaks? > > No way, I guess. We'll need to rethink the whole ALTER infrastructure > if things go south. Just like we always do. An alternative approach to this issue is attaching DDL triggers to txn statements and running rollback triggers "synchronously" while rolling back statements. This would allow us not to impose any strict requirements on how DDL triggers are implemented.