[MDEV-26138] innodb_flush_log_at_trx_commit=3 doesn't flush Created: 2021-07-14  Updated: 2021-07-23  Resolved: 2021-07-23

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.2, 10.3.0, 10.4.0, 10.5.0, 10.2.39
Fix Version/s: 10.2.40, 10.3.31, 10.4.21, 10.5.12, 10.6.4

Type: Bug Priority: Major
Reporter: Daniel Black Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: contribution, foundation, not-10.6

Issue Links:
Relates
relates to MDEV-232 Remove one fsync() inside engine's co... Closed

 Description   

"Since 10.2 this code was refactored to have switches in descending
order, so value of 3 for innodb_flush_log_at_trx_commit is behaving
the same as value of 2, that is no FSYNC is being enforced during
COMMIT phase. The switch should however not be empty and cases 2 and 3
should not have the identical contents."



 Comments   
Comment by Marko Mäkelä [ 2021-07-14 ]

The parameter value 3 was introduced in MDEV-232, and it has been effectively treated as innodb_flush_log_at_trx_commit=2 since the MariaDB 10.2.2 alpha release.

Would an alternative fix be acceptable? That is, let us remove the value 3 and have the server issue a warning that the value was clamped to 2? That would basically document the status quo. Does anyone really need the innodb_flush_log_at_trx_commit=3 behaviour that was introduced in MDEV-232?

3 (flush to disk at prepare and at commit, slower and usually redundant)

Comment by Marko Mäkelä [ 2021-07-15 ]

Because the documentation string for innodb_flush_log_at_trx_commit implies that the value 3 is ‘stronger’ than the value 1, it would seem wrong to keep treating it in a similar way as the ‘weaker’ value 2.

Overall, it seems to be simplest to fix the parameter to work as documented.

Generated at Thu Feb 08 09:43:02 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.