On Tue, May 06, 2008 at 02:59:16AM +0300, Michael Widenius wrote:
>
> Hi!
>
> >>>>> "Guilhem" == Guilhem Bichot <guilhem@stripped> writes:
>
> Guilhem> On Wed, Apr 23, 2008 at 01:38:50PM +0200, Guilhem Bichot wrote:
> >> Hello,
> >>
> >> this is the option you wanted - could you please have a look and tick
> >> some approval if you like it, or suggest changes?
> >> Thanks!
>
> Guilhem> To be more accurate: it's the WL task's descriptions which I am asking
> Guilhem> you to approve; the code is not yet written :)
>
> Approved.
As part of http://forge.mysql.com/worklog/task.php?id=4374,
I have enabled --maria-recover in Maria (not yet pushed). Now I'm
hitting a problem.
For non-transactional tables, no problem: after a crash, table has
open_count>0 and this triggers auto_check_and_repair.
For transactional tables, after a crash, assuming recovery was not
able to fix the table (log was broken for example), table has
open_count==0, so auto_check_and_repair will not run. Indeed, every
run-time operation, before it changes the table, calls
_ma_mark_file_changed(), which increments open_count and, _if_
non-transactional, stores it on disk. For a transactional table, it
sounded like an un-needed performance hit to do a pwrite() for
open_count at first open (and a corresponding one at close), given
that recovery is supposed to fix any problems in case of crash.
If I store open_count on disk for transactional tables that would be
one pwrite() at first open and one pwrite() at close.
I unfortunately don't see any other solution. Opinions?
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Guilhem Bichot <guilhem@stripped>
/ /|_/ / // /\ \/ /_/ / /__ MySQL France, Lead Software Engineer
/_/ /_/\_, /___/\___\_\___/ Bordeaux, France
<___/ www.mysql.com