Hi Sergei, thanks for explanations. So -1 -> new_file (my_repair()) is a problem while old_file -> new_file (mi_repair_by_sort()/mi_repair_parallel()) is somewhat acceptable. I was just confused by ma_repair_parallel() change, which seem to do old_file -> new_file too. Thanks, Sergey On Wed, May 27, 2015 at 10:07:07PM +0200, Sergei Golubchik wrote:
Hi, Sergey!
On May 27, Sergey Vojtovich wrote:
Hi Sergei,
I'm lost now. In Aria you did change very similar code and kept init_io_cache(-1) while init_io_cache(info->dfile) was moved down and replaced with init_io_cache(new_file). This sounds reasonable. FWICS MyISAM has very same code.
Isn't "temp" in fact info->dfile and not -1?
Ok, the original problem. init_io_cache(-1) means that IO_CACHE uses a temporary file as a backing store. That is, when in-memory buffer is full, IO_CACHE creates a temporary file to keep the data.
MyISAM in a couple of places was creating IO_CACHE with init_io_cache(-1) and later was replacing IO_CACHE::file. That is, IO_CACHE was created as if it was a temporary storage, but later changed to use a real file. Which is not a good idea now, as I (in a later changeset) detect temporary IO_CACHE's in init_io_cache.
So, I've fixed MyISAM/Aria not to access internal IO_CACHE fields and create IO_CACHE to have the correct file descriptior from the start.
Regards, Sergei