From: "n.pettik" <korablev@tarantool.org> To: tarantool-patches@freelists.org Cc: Imeev Mergen <imeevma@tarantool.org>, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: [tarantool-patches] Re: [PATCH v8 1/3] box: factor fiber_gc out of txn_commit Date: Tue, 30 Oct 2018 17:30:23 +0300 [thread overview] Message-ID: <D2850F80-C478-4C9C-ADDA-60FB9747CFAE@tarantool.org> (raw) In-Reply-To: <bcd32c9ee07f365efe142414f5456e34b7ae7bbb.1540832830.git.imeevma@gmail.com> > 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...
next prev parent reply other threads:[~2018-10-30 14:30 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-29 17:33 [tarantool-patches] [PATCH v8 0/3] sql: return all generated ids via IPROTO imeevma 2018-10-29 17:33 ` [tarantool-patches] [PATCH v8 1/3] box: factor fiber_gc out of txn_commit imeevma 2018-10-30 14:30 ` n.pettik [this message] 2018-10-30 19:15 ` [tarantool-patches] " Vladislav Shpilevoy 2018-10-30 20:03 ` Vladislav Shpilevoy 2018-10-30 20:06 ` Vladislav Shpilevoy 2018-10-30 21:32 ` Vladislav Shpilevoy 2018-10-30 23:08 ` n.pettik 2018-10-31 9:18 ` Vladislav Shpilevoy 2018-10-31 9:30 ` n.pettik 2018-10-29 17:33 ` [tarantool-patches] [PATCH v8 2/3] sql: return all generated ids via IPROTO imeevma 2018-10-30 14:30 ` [tarantool-patches] " n.pettik 2018-11-02 18:52 ` Imeev Mergen 2018-11-09 7:51 ` n.pettik 2018-10-29 17:33 ` [tarantool-patches] [PATCH v8 3/3] sql: remove psql_txn from Vdbe imeevma 2018-10-30 14:30 ` [tarantool-patches] " n.pettik 2018-10-30 19:41 ` Vladislav Shpilevoy 2018-11-09 8:02 ` [tarantool-patches] Re: [PATCH v8 0/3] sql: return all generated ids via IPROTO Kirill Yukhin
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=D2850F80-C478-4C9C-ADDA-60FB9747CFAE@tarantool.org \ --to=korablev@tarantool.org \ --cc=imeevma@tarantool.org \ --cc=tarantool-patches@freelists.org \ --cc=v.shpilevoy@tarantool.org \ --subject='[tarantool-patches] Re: [PATCH v8 1/3] box: factor fiber_gc out of txn_commit' \ /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