Thanks Pantelis
You're right that ON and OFF are switched around. I'll double check the
version that this changed - the 5.5 version of the MySQL docs at
http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_file_per_table
also say that this was changed in 5.5.7 (so it
Although the first MariaDB 5.5 release was 5.5.20... Anyway, fixed in
the docs now, thanks for the report.
On 08/05/2015 09:50, Ian Gilfillan wrote:
You're right that ON and OFF are switched around. I'll double check
the version that this changed - the 5.5 version of the MySQL docs at
Hi Ian, Pantelis,
What MySQL docs say is true, however confusing.
The value was switched ON in early versions of MySQL 5.5; caused some
problems; was switched back to OFF in 5.5.7; stayed OFF in all further
5.5 releases and early releases of 5.6; and was switched ON from 5.6.6.
For MariaDB
Hi, Reindl!
On May 07, Reindl Harald wrote:
No, it affects the server, not mysql_upgrade. But it's a new
statement, that mysql_upgrade is using, no existing query can
possibly trigger that bug
well, in other words anybody could crash the server by write a
specific query and so i am
Hi,
The log does not have whole pages. Pages must not be torn for the recovery
process to work. A fsync is required when a page is written to disk.
During recovery all changes since the last checkpoint are replayed, then
transactions that do not have a commit marker are rolled back. This is
Justin,
I was thinking of if fsync is needed each time after a write. The
operations are already in the log. So recovery can always be done from the
log. The difference is that during recovery, we need to go back further in
the log and it will take longer. But in that way, I guess it would be
6 matches
Mail list logo
