Last commit made on 2022-06-29
Get this branch:
git clone -b bb-10.6-midenok-MDEV-25004

Branch merges

Branch information


Recent commits

3a08c02... by midenok

Stopword upgrade/downgrade test

Plus some history generated to make stopword,vers_stopword better

e65d1d5... by midenok

vers/orig combinations for stopword table

dfc09a3... by midenok

MDEV-25004 innodb_fts.versioning upgrade/downgrade test for system versioning

OLD_BINDIR must point to previous revision build for this test to work
correctly (see comment in versioning.test).

3b9563b... by midenok

innodb_fts.basic split

6fff9d7... by midenok

MDEV-25004 restart_bindir option to restart server from different location

Adds new parameter $restart_bindir for


let $restart_bindir= /home/midenok/src/mariadb/10.3b/build;
--source include/

It is good to return back original server before check_mysqld will be
run at the test end:

let $restart_bindir=;
--source include/

054bb28... by midenok

MDEV-25004 FTS tests for System Versioning

MTR combination 'vers' for debug build sets sysvers_force and
sysvers_hide. sysvers_force makes every created table
system-versioned, sysvers_hide hides WITH SYSTEM VERSIONING for SHOW

MTR combination 'vers_trx' like 'vers' sets sysvers_force_trx and
sysvers_hide. That tests FTS with trx_id-based System Versioning.

To use 'vers' or 'vers_trx' combination one must include into his test.

Removed innodb-fts-stopword.test as it duplicates stopword.test

a2c1b39... by midenok

MDEV-25004 vers_force_trx option to force transactional System Versioning

Works like vers_force but forces trx_id-based system-versioned tables
if the storage supports it (currently InnoDB-only). Otherwise creates
timestamp-based system-versioned table.


b0177e4... by midenok

MDEV-25004 Missing row in FTS_DOC_ID_INDEX during DELETE HISTORY

1. In case of system-versioned table add row_end into FTS_DOC_ID index
   in fts_create_common_tables() and innobase_create_key_defs().
   fts_n_uniq() returns 1 or 2 depending on whether the table is

   After this patch recreate of FTS_DOC_ID index is required for
   existing system-versioned tables. If you see this message in error
   log or server warnings: "InnoDB: Table db/t1 contains 2 indexes
   inside InnoDB, which is different from the number of indexes 1
   defined in the MariaDB" use this command to fix the table:

      ALTER TABLE db.t1 FORCE;

2. Fix duplicate history for secondary unique index like it was done
   in MDEV-23644 for clustered index (932ec586aad). In case of
   existing history row which conflicts with currently inseted row we
   check in row_ins_scan_sec_index_for_duplicate() whether that row
   was inserted as part of current transaction. In that case we
   indicate with DB_FOREIGN_DUPLICATE_KEY that new history row is not
   needed and should be silently skipped.

3. Some parts of MDEV-21138 (7410ff436e9) reverted. Skipping of
   FTS_DOC_ID index for history rows made problems with purge
   system. Now this is fixed differently by p.2.

4. checks that we didn't affect non-history rows
   so they are deleted and purged correctly.

Additional FTS fixes

  fts_init_get_doc_id(): exclude history rows from max_doc_id
  calculation. fts_init_get_doc_id() callback is used only for crash

  fts_add_doc_by_id(): set max value for row_end field.

  fts_read_stopword(): stopwords table can be system-versioned too. We
  now read stopwords only for current data.

  row_insert_for_mysql(): exclude history rows from doc_id validation.

  row_merge_read_clustered_index(): exclude history_rows from doc_id

  fts_load_user_stopword(): for versioned table retrieve row_end field
  and skip history rows. For non-versioned table we retrieve 'value'
  field twice (just for uniformity).

2fa3ada... by Marko Mäkelä

Fix a sporadic failure of main.backup_locks

Ever since commit 9608773f75e2ca21491ef6825c3616cdc96d1ca5
the InnoDB persistent statistics are enabled on all InnoDB tables
by default. We must filter out any output that indicates that the
statistics tables are being internally accessed by InnoDB.

5e40934... by Monty <email address hidden>

MDEV-28897 Wrong table.get_ref_count() upon concurrent truncate and backup stage operation

The issue was that flush_tables() didn't take a MDL lock on cached
TABLE_SHARE before calling open_table() to do a HA_EXTRA_FLUSH call.
Most engines seams to have no issue with it, but apparantly this conflicts
with InnoDB in 10.6 when using TRUNCATE

Fixed by taking a MDL lock before trying to open the table in

There is no test case as it hard to repeat the scheduling that causes
the error. I did run the test case in MDEV-28897 to verify
that the bug is fixed.