Tarantool development patches archive
 help / color / mirror / Atom feed
From: Nikita Pettik <korablev@tarantool.org>
To: tarantool-patches@dev.tarantool.org
Cc: v.shpilevoy@tarantool.org
Subject: [Tarantool-patches] [PATCH] vinyl: add NULL check of xrow_upsert_execute() retval
Date: Wed, 27 May 2020 05:56:47 +0300	[thread overview]
Message-ID: <776e8b91b93c79dabd2932b5d665236c5da313c8.1590546551.git.korablev@tarantool.org> (raw)

xrow_upsert_execute() can fail and return NULL for various reasons.
However, in vy_apply_upsert() the result of xrow_upsert_execute() is
used unconditionally which may lead to crash. Let's fix it and in case
xrow_upsert_execute() fails return from vy_apply_upsert() NULL value.

Closes #4957
---
Brief problem description: if user puts a lot (more than 4000) of
upserts which modify the same tuple into one transaction, it may
lead to crash. Since the number of update operations exceeds the
limit (BOX_UPDATE_OP_CNT_MAX == 4000), they are not allowed to be
applied (still all upserts are squashed into one).
So xrow_upsert_execute() can return NULL instead ofvalid result
which will be dereferenced later.

Note that patch is based on np/gh-1622-skip-invalid-upserts branch.
If we don't skip invalid upsert which is the result of squashing
4000 other upserts, dump won't be able to finish due to raised error.

As a rule, all upserts modifying the same key are squashed and/or
executed during dump process. So basically users should not face
scenario when a lot of upserts get stuck in disk run. The only case
is invalid upserts which are not skipped (in contrast to branch
containing fix for 1622) and reside until squash with DELETE statement
(AFAIU). So I believe we should not bother with BOX_UPDATE_OP_CNT_MAX
restriction as it is mentioned in issue.

Branch: https://gitlab.com/tarantool/tarantool/pipelines/149917031
Issue: https://github.com/tarantool/tarantool/issues/4957

@ChangeLog:
 * Fix crash during squash of many (more than 4000) upserts modifying
the same key.

 src/box/vy_upsert.c                          |   4 +
 test/vinyl/gh-4957-too-many-upserts.result   | 118 +++++++++++++++++++
 test/vinyl/gh-4957-too-many-upserts.test.lua |  48 ++++++++
 3 files changed, 170 insertions(+)
 create mode 100644 test/vinyl/gh-4957-too-many-upserts.result
 create mode 100644 test/vinyl/gh-4957-too-many-upserts.test.lua

diff --git a/src/box/vy_upsert.c b/src/box/vy_upsert.c
index 6855b9820..007921bb2 100644
--- a/src/box/vy_upsert.c
+++ b/src/box/vy_upsert.c
@@ -133,6 +133,10 @@ vy_apply_upsert(const struct tuple *new_stmt, const struct tuple *old_stmt,
 					 new_ops_end, result_mp, result_mp_end,
 					 &mp_size, 0, suppress_error,
 					 &column_mask);
+	if (result_mp == NULL) {
+		region_truncate(region, region_svp);
+		return NULL;
+	}
 	result_mp_end = result_mp + mp_size;
 	if (tuple_validate_raw(format, result_mp) != 0) {
 		region_truncate(region, region_svp);
diff --git a/test/vinyl/gh-4957-too-many-upserts.result b/test/vinyl/gh-4957-too-many-upserts.result
new file mode 100644
index 000000000..203329788
--- /dev/null
+++ b/test/vinyl/gh-4957-too-many-upserts.result
@@ -0,0 +1,118 @@
+-- test-run result file version 2
+s = box.schema.create_space('test', {engine = 'vinyl'})
+ | ---
+ | ...
+pk = s:create_index('pk')
+ | ---
+ | ...
+s:insert{1, 1}
+ | ---
+ | - [1, 1]
+ | ...
+box.snapshot()
+ | ---
+ | - ok
+ | ...
+
+-- Let's test number of upserts in one transaction that exceeds
+-- the limit of operations allowed in one update.
+--
+ups_cnt = 5000
+ | ---
+ | ...
+box.begin()
+ | ---
+ | ...
+for i = 1, ups_cnt do s:upsert({1}, {{'&', 2, 1}}) end
+ | ---
+ | ...
+box.commit()
+ | ---
+ | ...
+dump_count = box.stat.vinyl().scheduler.dump_count
+ | ---
+ | ...
+tasks_completed = box.stat.vinyl().scheduler.tasks_completed
+ | ---
+ | ...
+box.snapshot()
+ | ---
+ | - ok
+ | ...
+
+fiber = require('fiber')
+ | ---
+ | ...
+while box.stat.vinyl().scheduler.tasks_inprogress > 0 do fiber.sleep(0.01) end
+ | ---
+ | ...
+
+assert(box.stat.vinyl().scheduler.dump_count - dump_count == 1)
+ | ---
+ | - true
+ | ...
+-- Last :snapshot() triggers both dump and compaction processes.
+--
+assert(box.stat.vinyl().scheduler.tasks_completed - tasks_completed == 2)
+ | ---
+ | - true
+ | ...
+
+s:select()
+ | ---
+ | - - [1, 1]
+ | ...
+
+s:drop()
+ | ---
+ | ...
+
+s = box.schema.create_space('test', {engine = 'vinyl'})
+ | ---
+ | ...
+pk = s:create_index('pk')
+ | ---
+ | ...
+
+tuple = {}
+ | ---
+ | ...
+for i = 1, ups_cnt do tuple[i] = i end
+ | ---
+ | ...
+_ = s:insert(tuple)
+ | ---
+ | ...
+box.snapshot()
+ | ---
+ | - ok
+ | ...
+
+box.begin()
+ | ---
+ | ...
+for k = 1, ups_cnt do s:upsert({1}, {{'+', k, 1}}) end
+ | ---
+ | ...
+box.commit()
+ | ---
+ | ...
+box.snapshot()
+ | ---
+ | - ok
+ | ...
+while box.stat.vinyl().scheduler.tasks_inprogress > 0 do fiber.sleep(0.01) end
+ | ---
+ | ...
+
+-- All upserts are ignored since they are squashed to one update
+-- operation with too many operations.
+--
+assert(s:select()[1][1] == 1)
+ | ---
+ | - true
+ | ...
+
+s:drop()
+ | ---
+ | ...
diff --git a/test/vinyl/gh-4957-too-many-upserts.test.lua b/test/vinyl/gh-4957-too-many-upserts.test.lua
new file mode 100644
index 000000000..6c201f29e
--- /dev/null
+++ b/test/vinyl/gh-4957-too-many-upserts.test.lua
@@ -0,0 +1,48 @@
+s = box.schema.create_space('test', {engine = 'vinyl'})
+pk = s:create_index('pk')
+s:insert{1, 1}
+box.snapshot()
+
+-- Let's test number of upserts in one transaction that exceeds
+-- the limit of operations allowed in one update.
+--
+ups_cnt = 5000
+box.begin()
+for i = 1, ups_cnt do s:upsert({1}, {{'&', 2, 1}}) end
+box.commit()
+dump_count = box.stat.vinyl().scheduler.dump_count
+tasks_completed = box.stat.vinyl().scheduler.tasks_completed
+box.snapshot()
+
+fiber = require('fiber')
+while box.stat.vinyl().scheduler.tasks_inprogress > 0 do fiber.sleep(0.01) end
+
+assert(box.stat.vinyl().scheduler.dump_count - dump_count == 1)
+-- Last :snapshot() triggers both dump and compaction processes.
+--
+assert(box.stat.vinyl().scheduler.tasks_completed - tasks_completed == 2)
+
+s:select()
+
+s:drop()
+
+s = box.schema.create_space('test', {engine = 'vinyl'})
+pk = s:create_index('pk')
+
+tuple = {}
+for i = 1, ups_cnt do tuple[i] = i end
+_ = s:insert(tuple)
+box.snapshot()
+
+box.begin()
+for k = 1, ups_cnt do s:upsert({1}, {{'+', k, 1}}) end
+box.commit()
+box.snapshot()
+while box.stat.vinyl().scheduler.tasks_inprogress > 0 do fiber.sleep(0.01) end
+
+-- All upserts are ignored since they are squashed to one update
+-- operation with too many operations.
+--
+assert(s:select()[1][1] == 1)
+
+s:drop()
\ No newline at end of file
-- 
2.17.1

             reply	other threads:[~2020-05-27  2:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27  2:56 Nikita Pettik [this message]
2020-05-29 21:24 ` Vladislav Shpilevoy
2020-05-29 21:34   ` Vladislav Shpilevoy
2020-07-08 12:22     ` Nikita Pettik
2020-05-29 23:04   ` Konstantin Osipov
2020-07-08 12:53   ` Nikita Pettik
2020-07-09 11:56     ` Nikita Pettik

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=776e8b91b93c79dabd2932b5d665236c5da313c8.1590546551.git.korablev@tarantool.org \
    --to=korablev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] vinyl: add NULL check of xrow_upsert_execute() retval' \
    /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