To fix MDEV-34483, mariadb-backup --backup needs to find out the current InnoDB log sequence number (LSN), which ideally is not much ahead the LSN of the latest InnoDB transaction commit.

If general_log=1 and log_output='TABLE', as is the case in the test mariabackup.log_tables, any SQL statement that is executed after the BACKUP STAGE BLOCK_COMMIT statement would be written to mysql.general_log, which in turn would mark the table as dirty. Had the mysql/general_log.* not been copied before that, the test would fail:

mysqltest: At line 40: query 'SELECT * FROM mysql.general_log

WHERE argument LIKE "INSERT INTO %" AND

(command_type = "Query" OR command_type = "Execute") ' failed: ER_KEY_NOT_FOUND (1032): Can't find record in 'general_log'

This is because in the file mysql/general_log.CSM the last byte would be 1, denoting that there may be outstanding writes to the mysql/general_log.CSV file and that REPAIR TABLE must be executed.

To avoid introducing such a regression in MDEV-34483, we have to wait for the asynchronous m_common_backup.copy_log_tables() to finish before we can execute a further SQL statement to find out the InnoDB LSN that we need to copy log for.

If BACKUP STAGE BLOCK_COMMIT returned an LSN (0 if InnoDB is not enabled), then we could allow truly asynchronous execution of m_common_backup.copy_log_tables() and let the backup finish faster. Similarly, the command could return whether ENGINE=RocksDB is enabled, so that we can avoid executing an extra SQL statement for that.