Marko Mäkelä 0ee1082bd2 MDEV-28495 InnoDB corruption due to lack of file locking ... Starting with commit da094188f6 (MDEV-24393), MariaDB will no longer acquire advisory file locks on InnoDB data files by default, because it would create a large number of entries in Linux /proc/locks. The motivation for acquiring the file locks is to prevent accidental concurrent startup of multiple server processes on the same data files. Such mistake still turns out to be relatively common, based on corruption bug reports from the community. To prevent corruption due to concurrent startup attempts, the Aria storage engine would unconditionally acquire an advisory lock on one of its log files. Solution: InnoDB will always lock its system tablespace files. (Ever since commit 685d958e38 the InnoDB log file will not necessarily be open while the server is running, because it can be accessed via memory-mapped I/O.) If more protection is desired, then the option --external-locking can be used. The mandatory advisory lock also fixes intermittent failures of some crash recovery tests. It turns out that when the mtr test harness kills and restarts the server, it will not actually ensure that the old process has terminated before starting the new one.		2022-07-27 14:15:14 +03:00
..
fil0crypt.cc	Merge branch 10.2 into 10.3	2021-12-23 14:14:04 +01:00
fil0fil.cc	MDEV-28495 InnoDB corruption due to lack of file locking	2022-07-27 14:15:14 +03:00
fil0pagecompress.cc	Merge 10.2 into 10.3	2020-08-13 18:18:25 +03:00