Tarantool development patches archive
 help / color / mirror / Atom feed
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 v2 1/2] sql: proper check for index in sqlite3Insert()
Date: Thu, 15 Nov 2018 16:47:44 +0300	[thread overview]
Message-ID: <6B17B69F-F470-4010-8B60-B7233317C060@tarantool.org> (raw)
In-Reply-To: <05acfbeed0d0a02a349aa1ceb5a44624ff333060.1542282499.git.imeevma@gmail.com>



> On 15 Nov 2018, at 15:09, imeevma@tarantool.org wrote:
> 
> Index received in function sqlite3Insert() wasn't checked
> properly. It lead to segmentation fault when INSERT and

Typo: led (or leads).

> DROP TABLE executed simultaneously for the same table.

This particular fix seems to be OK, but what about other cases?
For example executing different SELECTs when table/index is dropped,
or executing deletes/updates, or executing INSERT with different riggers
or foreign keys and so on and so forth.

Could you please spend some time to deeply investigate this issue?
I am afraid that SQL in its current state is unlikely to be adopted to
such emergencies...

> 
> Closes #3780
> ---
> src/box/sql/insert.c     | 49 ++++++++++++++++++++++++------------------------
> test/sql/errinj.result   | 33 ++++++++++++++++++++++++++++++++
> test/sql/errinj.test.lua | 12 ++++++++++++
> 3 files changed, 69 insertions(+), 25 deletions(-)
> 
> @@ -315,24 +314,21 @@ sqlite3Insert(Parse * pParse,	/* Parser context */
> 	if (pTab == NULL)
> 		goto insert_cleanup;
> 
> -	space_id = pTab->def->id;
> +	struct space *space = pTab->space;
> +	struct space_def *def = space->def;
> +	space_id = def->id;

Small refactoring:

diff --git a/src/box/sql/insert.c b/src/box/sql/insert.c
index 6f7720201..235be2b9f 100644
--- a/src/box/sql/insert.c
+++ b/src/box/sql/insert.c
@@ -281,7 +281,6 @@ sqlite3Insert(Parse * pParse,       /* Parser context */
        int regTupleid;         /* registers holding insert tupleid */
        int regData;            /* register holding first column to insert */
        int *aRegIdx = 0;       /* One register allocated to each index */
-       uint32_t space_id = 0;
        /* List of triggers on pTab, if required. */
        struct sql_trigger *trigger;
        int tmask;              /* Mask of trigger times */
@@ -316,7 +315,7 @@ sqlite3Insert(Parse * pParse,       /* Parser context */
 
        struct space *space = pTab->space;
        struct space_def *def = space->def;
-       space_id = def->id;
+       uint32_t space_id = def->id;

> 
> 	/* Figure out if we have any triggers and if the table being
> 	 * inserted into is a view
> 	 */
> 	trigger = sql_triggers_exist(pTab, TK_INSERT, NULL, &tmask);
> -	bool is_view = pTab->def->opts.is_view;
> +	bool is_view = def->opts.is_view;
> 	assert((trigger != NULL && tmask != 0) ||
> 	       (trigger == NULL && tmask == 0));
> 
> -	/* If pTab is really a view, make sure it has been initialized.
> -	 * ViewGetColumnNames() is a no-op if pTab is not a view.
> -	 */
> -	if (is_view &&
> -	    sql_view_assign_cursors(pParse, pTab->def->opts.sql) != 0)
> +	if (is_view && sql_view_assign_cursors(pParse, def->opts.sql) != 0)
> 		goto insert_cleanup;
> 
> -	struct space_def *def = pTab->def;
> 	/* Cannot insert into a read-only table. */
> 	if (is_view && tmask == 0) {
> 		sqlite3ErrorMsg(pParse, "cannot modify %s because it is a view",
> @@ -340,6 +336,12 @@ sqlite3Insert(Parse * pParse,	/* Parser context */
> 		goto insert_cleanup;
> 	}
> 
> +	if (! is_view && index_find(space, 0) == NULL) {
> +		pParse->nErr++;
> +		pParse->rc = SQL_TARANTOOL_ERROR;
> +		goto insert_cleanup;
> +	}

Please, put explanation comment here. In a few weeks everyone
will forget about this bug, so this snippet will look quite strange.

Also, lets separate refactoring (in our case substituting usage of
struct Table with struct space) and functional changes (validating PK)
and put them into different commits (not now but for the next patches).
I know that in SQL patches as a rule they come together since there are
a lot of codestyle violations, but it makes reviewing process MUCH more easier.

  reply	other threads:[~2018-11-15 13:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15 12:09 [tarantool-patches] [PATCH v2 0/2] " imeevma
2018-11-15 12:09 ` [tarantool-patches] [PATCH v2 1/2] " imeevma
2018-11-15 13:47   ` n.pettik [this message]
2018-11-15 12:09 ` [tarantool-patches] [PATCH v2 2/2] sql: remove space_column_default_expr() imeevma
2018-11-15 13:47   ` [tarantool-patches] " n.pettik
2018-11-15 12:27 ` [tarantool-patches] Re: [PATCH v2 0/2] sql: proper check for index in sqlite3Insert() Vladislav Shpilevoy

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=6B17B69F-F470-4010-8B60-B7233317C060@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 v2 1/2] sql: proper check for index in sqlite3Insert()' \
    /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