Test case #1 (based on MDEV-16759).

git clone https://github.com/elenst/rqg --branch mdev16759 rqg-mdev16759

cd rqg-mdev16759/

perl ./runall-new.pl --basedir=/data/releases/10.1.29  --vardir=/data/logs/vardir  --duration=3600 --threads=1   --grammar=mdev16759.yy --skip-gendata

Definitely affected versions/builds:

• 10.1.29 non-debug (local)
• 10.1.32 non-debug (local, travis)
• 10.1.33 non-debug (local), debug (travis)
• 10.1.34 non-debug (travis)

Possibly affected versions/builds (different failures):

• 10.1.34 debug (travis)

  Version: '10.1.34-MariaDB-debug' socket: '/home/travis/logs/vardir/mysql.sock' port: 19300 Source distribution

  InnoDB: tried to purge sec index entry not marked for deletion in

  InnoDB: index "PDNoteContent" of table "test"."notes"

  InnoDB: tuple DATA TUPLE: 2 fields;

  0: SQL NULL;

  1: len 4; hex 80000506; asc ;;

  InnoDB: record PHYSICAL RECORD: n_fields 2; compact format; info bits 0

  0: SQL NULL;

  1: len 4; hex 80000506; asc ;;

  2018-07-29 21:07:43 7f8ab91c7700 InnoDB: Assertion failure in thread 140233787864832 in file row0purge.cc line 479

  InnoDB: Failing assertion: 0

Not affected versions/builds:

• Current 10.1 non-debug, and previous revisions since c4eb4bcef648eb2ebdc6edc06905f39f95ef7f6b
• 10.1.28 and earlier releases, and anything before 51b4366bfb8a77c6341d7811f71c851e52f36f68

Checked workarounds

• innodb_change_buffering=none – no effect
• innodb_adaptive_hash_index=off – seems to help

TBC

Test case #2 (temporary tables)

t65.test

perl ./mtr bug.t65 --mysqld=--innodb --mysqld=--partition --mysqld=--default-storage-engine=InnoDB --mysqld=--sql-mode= --mem --mysqld=--innodb_change_buffering=none --mysqld=--innodb-adaptive-hash-index=off --mysqld=--max-statement-time=6 --mysqld=--lock-wait-timeout=4 --mysqld=--loose-innodb-lock-wait-timeout=2 --mysqld=--innodb_buffer_pool_size=128M --mysqld=--innodb_log_buffer_size=16M --mysqld=--innodb_log_file_size=48M --mysqld=--innodb_lru_scan_depth=1024 --mysqld=--innodb_stats_persistent=ON --mysqld=--innodb_read_io_threads=4 --mysqld=--innodb_write_io_threads=4

The test case was initially mentioned in the comment to MDEV-14643. The test case was never finalized, because by the time it was produced, the variation of the problem it reproduces had already been fixed in the scope of MDEV-16868 (commit 1b4c5b7327e84).

Affected versions:

10.2.16 non-debug (local)
10.2.17 non-debug (local)

I don't have information about other versions, but the patch which fixed it went to 10.2.18 and 10.3.10.

Test case #3 (indexed virtual columns)

--source include/have_innodb.inc

CREATE TABLE t1 ( 

  pk SERIAL,

  b LONGTEXT NOT NULL DEFAULT '',

  c CHAR(179) NOT NULL DEFAULT '',

  v LONGTEXT AS (b) VIRTUAL,

  PRIMARY KEY(pk),

  INDEX (v(64)),

  INDEX (b(64))

) ENGINE=InnoDB;

INSERT INTO t1 (b) VALUES ('foo');

SELECT pk, b, c FROM t1 INTO OUTFILE 'load.data';

--let $run= 1000

while ($run)

{

  LOAD DATA INFILE 'load.data' REPLACE INTO TABLE t1 (pk,b,c);

  --dec $run

}

# Cleanup

DROP TABLE t1;

--let $datadir= `SELECT @@datadir`

--remove_file $datadir/test/load.data

The test case was initially mentioned in the comment to MDEV-14643.
The variation of the problem it reproduces was apparently fixed in the scope of MDEV-15114 (commit ab194666564a).

Affected versions:

10.2.15 non-debug (local)

Not affected versions:

10.2.16 non-debug (local)

I don't have information about other versions, but the patch which presumably fixed it went to 10.2.16 and 10.3.8.

Test case #4 (foreign keys)

--source include/have_innodb.inc

CREATE TABLE t1 (

  pk INT,

  a INT,

  b INT,

  PRIMARY KEY (pk),

  KEY (b)

) ENGINE=InnoDB;

INSERT INTO t1 VALUES  

(1,9,4),(2,0,0),(3,0,0),(4,5,0),(5,0,0),(6,0,3),(7,0,4),(8,3,9),(9,0,0),

(10,0,0),(11,9,0),(12,0,9),(13,9,0),(14,4,5),(15,0,0),(16,0,0);

ALTER TABLE t1 ADD CONSTRAINT FOREIGN KEY (a) REFERENCES t1 (b) ON DELETE CASCADE;

DELETE IGNORE FROM t1 WHERE b = 4;

INSERT IGNORE INTO t1 VALUES  

(1,9,4),(2,0,0),(3,0,0),(4,5,0),(5,0,0),(6,0,3),(7,0,4),(8,3,9),(9,0,0),

(10,0,0),(11,9,0),(12,0,9),(13,9,0),(14,4,5),(15,0,0),(16,0,0);

# Cleanup

DROP TABLE t1;

It's a new one as of the moment of writing this comment; it has been filed for now as MDEV-18272, to avoid assumptions about relation to other bug reports.

Affected versions:
10.2.15 non-debug
Current 10.2 a8a27e65 (post-10.2.21) non-debug
10.3.12 non-debug
Current 10.3 848fd3f7653 non-debug
Current 10.4 b13d356af8 non-debug

Not affected versions:
Current 10.1 69328c31ed

I don't have information about earlier versions.

If I remember correctly, now is (again) the period when we think the epic problem has been fixed, so I'm closing this.