This is definitely caused by MDEV-12288 or MDEV-13536, and the ALTER TABLE…LOCK=NONE logic needs to be revised.

There are a few options:

1. Suspend the purge during online ALTER TABLE (and remove row_log_table_blob_t which would become dead code). Drawback: buildup of lots of purge lag during a massive online ALTER TABLE
2. Introduce something similar to row_log_table_blob_t to keep track of (PRIMARY KEY,DB_TRX_ID) that have been reset during purge.
3. Carefully review the logic, and treat the value DB_TRX_ID=0 in the record as something that matches a no-longer-existing DB_TRX_ID in the online_log. Or, simply map no-longer-existing DB_TRX_ID to 0 in row_merge_read_clustered_index() and when writing the online_log.

elenst, can you observe any other failures in row0log.cc when there are no concurrent DELETE operations?

marko,

> Elena Stepanova, can you observe any other failures in row0log.cc when there are no concurrent DELETE operations?

I haven't yet, but there hasn't been enough testing yet to say for sure there are none. I'll keep watching.

A side note (unrelated to MDEV-12288 and MDEV-13536, but related to ha_innobase::inplace_alter_table) – testing around this area regularly hits my everlasting draft MDEV-10706 , which remains draft because so far I couldn't make up even a marginally reliable test case, although I hit the failure on average once out of 20-30 times in concurrent tests. If you encounter it too, I can confirm with certainty that it's not a new issue.

The innodb.innodb-table-online test that I imported into 10.0 (and merged up to 10.2 so far) as part of MDEV-13625 is repeating the same problem, for applying an update instead of an insert:

			/* The ROW_T_UPDATE was logged for a different

			DB_TRX_ID,DB_ROLL_PTR. This is possible if an

			earlier ROW_T_INSERT or ROW_T_UPDATE was diverted

			because some BLOBs were missing due to rolling

			back the initial insert or due to purging

			the old BLOB values of an update. */

			ut_ad(log->blobs);

CURRENT_TEST: innodb.innodb-table-online

mysqltest: At line 274: query 'reap' failed: 2013: Lost connection to MySQL server during query

I made a simple change that makes row_merge_read_clustered_index() reset DB_TRX_ID,DB_ROLL_PTR in the row->fields[] when the history is not needed (when the DB_TRX_ID refers to a no-longer-active transaction).
With this change, innodb.innodb-table-online passes and the provided test case does not crash.

The remaining question is: Do the callers of row_log_table_open() need any adjustment?
That is, can purge reset DB_TRX_ID of transactions that were active when the ALTER TABLE transaction passed ha_innobase::prepare_inplace_alter_table()?
The answer is a firm NO, because purge is not allowed to discard any history that is visible to currently active transactions.

A further observation is that ha_innobase::prepare_inplace_alter_table() acts as a barrier. During the execution of this function, both MDL_EXCLUSIVE lock on the table name and a LOCK_X on the dict_table_t will be held for some time. These locks cannot be granted until any concurrent transactions that accessed these tables (the MDL_EXCLUSIVE blocks even non-locking MVCC reads). So, any active transaction that was observed during ha_innobase::inplace_alter_table() in row_merge_read_clustered_index() or thereafter, would necessarily have been started after ha_innobase::prepare_inplace_alter_table() returned and the exclusive lock was downgraded.

Note: After a table-rebuilding ALTER TABLE…LOCK=NONE, it could be unavoidable to have some nonzero DB_TRX_ID columns in the table. Especially with DROP PRIMARY KEY, ADD PRIMARY KEY, the apply logic partly identifies the rows by the combination of PRIMARY KEY and DB_TRX_ID. These nonzero DB_TRX_ID would necessarily refer to concurrent DML operations that were started during ha_innobase::inplace_alter_table().

One more consideration is what happens in an online table-rebuilding ALTER TABLE after upgrading from MariaDB 10.3.0 or earlier.
In the old data file, we would necessarily have some clustered index records where a non-zero DB_TRX_ID column refers to a purged transaction.

With the above mentioned change to row_merge_read_clustered_index(), the initial rebuild of the table would reset DB_TRX_ID,DB_ROLL_PTR in the table.
But, what would happen on row_log_table_apply()?
The functions row_log_table_update() and row_log_table_delete() would be writing these non-canonical column values to the online_log, causing a mismatch when applying the log.

For row_log_table_delete(), the fix seems simple: treat the parameter sys=NULL as a request to reset the DB_TRX_ID,DB_ROLL_PTR in the log record. The only caller with non-NULL value is the ROLLBACK of an UPDATE, which needs to reset the original value. (As noted above, such rollback can only be a rollback of a transaction that was started after ha_innobase::prepare_inplace_alter_table() returned.) If the update that is now being rolled back was operating on a record whose DB_TRX_ID referred to a purged transaction (from before the upgrade), then we should reset the fields in the log record.

For row_log_table_update(), there is the parameter old_pk=row_log_table_get_pk() that is used during ADD PRIMARY KEY. The DB_TRX_ID in the old_pk parameter could refer to a purged transaction. If that is the case, we should reset the DB_TRX_ID,DB_ROLL_PTR in old_pk.

With these changes to the logging, row_log_table_apply() should always find a match between the rebuilt table (which would contain DB_TRX_ID=0 most of the time) and the online_log.

Again, the problem only affects a table-rebuilding ALTER TABLE…LOCK=NONE. There is also row_log_apply() for ADD INDEX and ADD UNIQUE INDEX when the table is not being rebuilt, and that logging is unaffected by this, because secondary indexes do not contain DB_TRX_ID columns (only the PAGE_MAX_TRX_ID in leaf pages).

bb-10.3-marko

ok to push.