commit e797a7483c0608c9c793f7388a2e446d2528768d
from: Vladimir Davydov <vdavydov@tarantool.org>
via: Vladimir Davydov <vdavydov.dev@gmail.com>
date: Fri Jun 24 12:59:58 2022 UTC

vinyl: rotate active memory index in vy_squash_process if necessary

If vy_point_lookup called by vy_sauash_process yields (doing disk read),
a dump may be triggered bumping the L0 generation counter, in which case
we would insert a statement to a sealed vy_mem, as explained in #5080.
Let's check the generation counter and rotate the active vy_mem if
necessary after vy_point_lookup to avoid that.

Closes #5080

NO_DOC=bug fix
NO_TEST=complicated, need stress/perf test to catch bugs like this

commit - 415d8b259a6d4986cc379173f473e6179e3f6cf2
commit + e797a7483c0608c9c793f7388a2e446d2528768d
blob - /dev/null
blob + ea5590382cf1884bdae325518a4fc991d125781f (mode 644)
--- /dev/null
+++ changelogs/unreleased/gh-5080-vy-mem-generation-fix.md
@@ -0,0 +1,4 @@
+## bugfix/vinyl
+
+* Fixed a bug in Vinyl upsert squashing optimization that could lead to
+  a segmentation fault error (gh-5080).
blob - 2dd114a4a734f0c52367568a63242d49dd2381e4
blob + 7b8db09b1ae436370bfccae3600929f008f905d0
--- src/box/vinyl.c
+++ src/box/vinyl.c
@@ -3324,6 +3324,16 @@ vy_squash_process(struct vy_squash *squash)
 		return -1;
 	if (result.stmt == NULL)
 		return 0;
+
+	/*
+	 * While we yielded in vy_point_lookup() above, the memory
+	 * generation could have been bumped so we might need to
+	 * rotate the active in-memory index.
+	 */
+	if (vy_lsm_rotate_mem_if_required(lsm) != 0) {
+		tuple_unref(result.stmt);
+		return -1;
+	}
 
 	/*
 	 * While we were reading on-disk runs, new statements could