| Bug #104324 | innodb early lock release problem | ||
|---|---|---|---|
| Submitted: | 15 Jul 2021 9:05 | Modified: | 15 Jul 2021 12:05 |
| Reporter: | pokemon wei | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S3 (Non-critical) |
| Version: | 8.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | lock, log, read | ||
[15 Jul 2021 10:41]
MySQL Verification Team
Hi Mr. pokemon, Thank you for your bug report. We are quite cognisant of all the concurrency problems that might occur in InnoDB SE. However, we do not see that your scenario is even theoretically possible. Hence, in order to further process this report, we need a fully repeatable test case that will prove your point. Otherwise, we have to close this bug report. We are waiting on your feedback.
[15 Jul 2021 12:03]
pokemon wei
sorry, i can't provide test cases for this. But i think it is a common problem for elr(early lock release) in database.
[15 Jul 2021 12:05]
pokemon wei
If you don't think it's a problem, i will close this bug report.
[16 Jul 2021 20:50]
Alexey Kopytov
This looks like a duplicate of bug #74303 which is in the Verified status.
[19 Jul 2021 12:09]
MySQL Verification Team
It is similar, but not a duplicate .....
Description: ``` trx_release_impl_and_expl_locks(trx, serialised); ... lsn_t lsn = mtr->commit_lsn(); if (lsn == 0) { /* Nothing to be done. */ } else if (trx->flush_log_later) { /* Do nothing yet */ trx->must_flush_log_later = true; /* Remember current ddl_operation, because trx_init() later will set ddl_operation to false. And the final flush is even later. */ trx->ddl_must_flush = trx->ddl_operation; } else if ((srv_flush_log_at_trx_commit == 0 || thd_requested_durability(trx->mysql_thd) == HA_IGNORE_DURABILITY) && (!trx->ddl_operation)) { /* Do nothing */ } else { trx_flush_log_if_needed(lsn, trx); } trx->commit_lsn = lsn; ``` In innodb, trx will release lock before flush redo log into disk. If T1 release lock before log flushing, T2 can read the modification of T1. There is a crash before T1 flushing log. T2 may return incorrect result to client before crash. Because the redo log of T1 can’t found on disk and T1 can’t be recoverd. How to repeat: Not a practical bug. It is a theoretical source code problem.