Tarantool development patches archive
 help / color / mirror / Atom feed
From: "Alexander V. Tikhonov" <avtikhon@tarantool.org>
To: Nikita Pettik <korablev@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] vinyl: update gh-4957-too-many-upserts test
Date: Tue, 17 Nov 2020 22:51:51 +0300	[thread overview]
Message-ID: <20201117195151.GA80591@hpalx> (raw)
In-Reply-To: <2161b3318413560c0145f011a62c395b5e4fffad.1604425009.git.korablev@tarantool.org>

Hi Nikita, thanks for the patch, as I see no new degradations found in
gitlab-ci testing commit criteria pipeline [1], patch LGTM.

[1] - https://gitlab.com/tarantool/tarantool/-/pipelines/217447464

On Tue, Nov 03, 2020 at 08:37:33PM +0300, Nikita Pettik wrote:
> After upsert rework in 5a61c4717 (#5107 issue) update operations are
> applied consistently corresponding to upserts they belong to: if update
> operation from single upsert fails - all update operations from that
> upsert are skipped. But the rest of update operations related to other
> upserts (after squashing two upserts) are applied. So let's update #4957
> test case: now upsert operation can be processed only if it contains
> more than BOX_UPDATE_OP_CNT_MAX (4000) operations before (before
> squashing with any other upsert).
> 
> Follow-up #4957
> Follow-up #5107
> ---
> Branch: https://github.com/tarantool/tarantool/tree/np/gh-4957-test-follow-up
> 
>  test/vinyl/gh-4957-too-many-upserts.result   | 49 +++++++++++++++-----
>  test/vinyl/gh-4957-too-many-upserts.test.lua | 29 ++++++++----
>  2 files changed, 58 insertions(+), 20 deletions(-)
> 
> diff --git a/test/vinyl/gh-4957-too-many-upserts.result b/test/vinyl/gh-4957-too-many-upserts.result
> index c942e62c8..d70a2e668 100644
> --- a/test/vinyl/gh-4957-too-many-upserts.result
> +++ b/test/vinyl/gh-4957-too-many-upserts.result
> @@ -32,26 +32,24 @@ ups_cnt = 5000
>  box.begin()
>   | ---
>   | ...
> -for i = 1, ups_cnt do s:upsert({1}, {{'&', 2, 1}}) end
> +for i = 1, ups_cnt do s:upsert({1}, {{'|', 2, i}}) end
>   | ---
>   | ...
>  box.commit()
>   | ---
>   | ...
> --- Upserts are not able to squash, so scheduler will get stuck.
> --- So let's not waste much time here, just check that no crash
> --- takes place.
> +-- Since 2.6 update operations of single upsert are applied consistently.
> +-- So despite upserts' update operations can be squashed, they are anyway
> +-- applied as they come in corresponding upserts. The same concerns the
> +-- second test.
>  --
>  box.snapshot()
>   | ---
>   | - ok
>   | ...
> -
> -fiber = require('fiber')
> - | ---
> - | ...
> -fiber.sleep(0.01)
> +s:select()
>   | ---
> + | - - [1, 8191]
>   | ...
>  
>  s:drop()
> @@ -82,7 +80,7 @@ box.snapshot()
>  box.begin()
>   | ---
>   | ...
> -for k = 1, ups_cnt do s:upsert({1}, {{'+', k, 1}}) end
> +for k = 2, ups_cnt do s:upsert({1}, {{'+', k, 1}}) end
>   | ---
>   | ...
>  box.commit()
> @@ -92,10 +90,39 @@ box.snapshot()
>   | ---
>   | - ok
>   | ...
> -fiber.sleep(0.01)
> +s:select()[1][ups_cnt]
> + | ---
> + | - 5001
> + | ...
> +
> +s:drop()
>   | ---
>   | ...
>  
> +-- Test that single upsert with too many (> 4000) operations doesn't
> +-- pass check so it is rejected.
> +--
> +s = box.schema.create_space('test', {engine = 'vinyl'})
> + | ---
> + | ...
> +pk = s:create_index('pk')
> + | ---
> + | ...
> +
> +ups_ops = {}
> + | ---
> + | ...
> +for k = 2, ups_cnt do ups_ops[k] = {'+', k, 1} end
> + | ---
> + | ...
> +s:upsert({1}, ups_ops)
> + | ---
> + | - error: Illegal parameters, too many operations for update
> + | ...
> +s:select()
> + | ---
> + | - []
> + | ...
>  s:drop()
>   | ---
>   | ...
> diff --git a/test/vinyl/gh-4957-too-many-upserts.test.lua b/test/vinyl/gh-4957-too-many-upserts.test.lua
> index 572540a4c..48e923bf1 100644
> --- a/test/vinyl/gh-4957-too-many-upserts.test.lua
> +++ b/test/vinyl/gh-4957-too-many-upserts.test.lua
> @@ -12,16 +12,15 @@ box.snapshot()
>  --
>  ups_cnt = 5000
>  box.begin()
> -for i = 1, ups_cnt do s:upsert({1}, {{'&', 2, 1}}) end
> +for i = 1, ups_cnt do s:upsert({1}, {{'|', 2, i}}) end
>  box.commit()
> --- Upserts are not able to squash, so scheduler will get stuck.
> --- So let's not waste much time here, just check that no crash
> --- takes place.
> +-- Since 2.6 update operations of single upsert are applied consistently.
> +-- So despite upserts' update operations can be squashed, they are anyway
> +-- applied as they come in corresponding upserts. The same concerns the
> +-- second test.
>  --
>  box.snapshot()
> -
> -fiber = require('fiber')
> -fiber.sleep(0.01)
> +s:select()
>  
>  s:drop()
>  
> @@ -34,11 +33,23 @@ _ = s:insert(tuple)
>  box.snapshot()
>  
>  box.begin()
> -for k = 1, ups_cnt do s:upsert({1}, {{'+', k, 1}}) end
> +for k = 2, ups_cnt do s:upsert({1}, {{'+', k, 1}}) end
>  box.commit()
>  box.snapshot()
> -fiber.sleep(0.01)
> +s:select()[1][ups_cnt]
> +
> +s:drop()
> +
> +-- Test that single upsert with too many (> 4000) operations doesn't
> +-- pass check so it is rejected.
> +--
> +s = box.schema.create_space('test', {engine = 'vinyl'})
> +pk = s:create_index('pk')
>  
> +ups_ops = {}
> +for k = 2, ups_cnt do ups_ops[k] = {'+', k, 1} end
> +s:upsert({1}, ups_ops)
> +s:select()
>  s:drop()
>  
>  -- restart the current server to resolve the issue #5141
> -- 
> 2.17.1
> 

  parent reply	other threads:[~2020-11-17 19:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03 17:37 Nikita Pettik
2020-11-11 21:55 ` Vladislav Shpilevoy
2020-11-13  0:22   ` Nikita Pettik
2020-11-16 21:24     ` Vladislav Shpilevoy
2020-11-17 19:51 ` Alexander V. Tikhonov [this message]
2020-11-17 20:26   ` 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=20201117195151.GA80591@hpalx \
    --to=avtikhon@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] vinyl: update gh-4957-too-many-upserts test' \
    /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