[futureweb]

• The Jira issue number for this PR is: MDEV-41752

Description

This branch contains the commit of MDEV-41747 (#5963). Please merge it after #5963.

A table whose fulltext index uses a parser plugin has HA_OPTION_RELIES_ON_SQL_LAYER, and maria_open() refuses it with HA_ERR_UNSUPPORTED unless HA_OPEN_FROM_SQL_LAYER is set. In the server only ha_maria::open() set it, so these opens failed:

• maria_rename(): RENAME TABLE, and the renames at the end of ALTER TABLE ... ALGORITHM=COPY, including ALTER TABLE ... ADD FULLTEXT ... WITH PARSER.
• create_new_data_handle(): REPAIR TABLE without QUICK of a ROW_FORMAT=PAGE table, which then stayed marked as crashed.
• new_table() in crash recovery, which then skipped the REDO records of the table, so committed rows were lost.

Before:

RENAME TABLE t1 TO t2;
Error on rename of './test/t1' to './test/t2' (errno: 138 "Unsupported extension used for table")

In the recovery example of the Jira issue, SELECT COUNT(*) returns 3 after the kill and restart (5 without WITH PARSER), and the error log shows ***WARNING: ./test/t1 could not be opened: Error: 138. After: the statements work, and recovery applies the REDO records of such tables.

Fix:

• Inside the server, open such tables with HA_OPEN_FROM_SQL_LAYER in these places. maria_rename() retries with the flag after HA_ERR_UNSUPPORTED when it runs inside the server (maria_in_ha_maria), so that the state LSN side effect of the flag applies only to tables that need it. create_new_data_handle() sets it for such tables; the keys are rebuilt through the handle that the SQL layer opened, which has the parser. Server recovery passes it for every table (aria_read_log does not): for the other tables its only effect, the state LSN update, already follows from maria_in_recovery. Recovery applies logged rows and key values and needs no parser.
• Recovery cannot replay REDO_REPAIR_TABLE for such a table, because the parser plugin is not loaded yet. It skips the record and keeps the files of the repair. To make that safe, write_log_record_for_repair() now syncs the files of such a table before it logs the repair; flushing the pages does not make them durable. Marking the table as crashed instead would make recovery skip all later REDO records of the table, which can be committed changes.
• If recovery finds such a table crashed, the message says REPAIR TABLE instead of aria_chk -r.

aria_chk and aria_read_log still refuse such tables. The debug points maria_crash_after_repair_log and maria_before_repair_log are for the test. With the ngram parser proposed in MDEV-10267, Aria tables WITH PARSER ngram hit this as well.

Release Notes

Aria tables with a fulltext index that uses a parser plugin can be renamed, changed with ALTER TABLE ... ALGORITHM=COPY and repaired. Crash recovery no longer skips such tables, which lost committed changes.

How can this PR be tested?

New tests maria.fulltext_parser and, for debug builds, maria.fulltext_parser_debug. Both use the simple_parser plugin from mypluglib and are skipped if it is not built. fulltext_parser: RENAME TABLE, ALTER TABLE ... ALGORITHM=COPY, ADD FULLTEXT ... WITH PARSER, REPAIR TABLE (default, QUICK, EXTENDED) and OPTIMIZE TABLE for ROW_FORMAT=PAGE and DYNAMIC; recovery of committed rows after a kill; rollback of an uncommitted transaction during recovery; recovery after a bulk insert repair. fulltext_parser_debug: a crash right after REDO_REPAIR_TABLE is logged, and changes committed after a repair record. Without the fix, RENAME TABLE fails with errno 138 and the recovered table misses the committed rows.

The maria and plugins suites and the main fulltext, plugin and alter tests pass on 11.4 (debug build). On main with all our fixes and the ngram parser of MDEV-10267, the innodb_fts, maria and plugins suites and the main fulltext, plugin and alter tests pass.

Basing the PR against the correct MariaDB version

• This is a new feature and the PR is based against the latest MariaDB development branch.
• This is a bug fix and the PR is based against the earliest maintained branch in which the bug can be reproduced. (10.11 has the same code, but its first GA release is more than three years old. We can rebase onto 10.11 if wanted.)

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

🤖 Generated with Claude Code