From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id EB0E92EB5C for ; Tue, 30 Oct 2018 10:30:26 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YLZ1jrdvsnM for ; Tue, 30 Oct 2018 10:30:26 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id A48C42EB56 for ; Tue, 30 Oct 2018 10:30:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: [tarantool-patches] Re: [PATCH v8 1/3] box: factor fiber_gc out of txn_commit From: "n.pettik" In-Reply-To: Date: Tue, 30 Oct 2018 17:30:23 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: Imeev Mergen , Vladislav Shpilevoy > On 29 Oct 2018, at 20:33, imeevma@tarantool.org wrote: > > Now txn_commit is judge, jury and executioner. It both > commits or rollbacks data, and collects it calling fiber_gc, > which destroys the region. Nit: both commits and rollbacks. > > But SQL wants to use some transactional data after commit. It is > autogenerated identifiers - a list of sequence values generated > for autoincrement columns and explicit sequence:next() calls. > > It is possible to store the list on malloced mem inside Vdbe, but > it complicates deallocation. What is the problem with deallocation? AFAIU it is enough to simply iterate over the list and release each element - not big deal. If you want to use region, mb it is worth to store separate region specially for VDBE? We already have it in parser, so what prevents us for adding the same thing to VDBE? I guess we can store many things there, not only list of ids. I understand that parser in its turn has nothing in common (at least it should, except for analyze machinery) with transaction routines, so separate region is likely to be more reasonable for parser, but anyway...