database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00
Code Activity

Merge baker@bk-internal.mysql.com:/home/bk/mysql-4.1

Browse Source 
into zim.(none):/home/brian/mysql/mysql-4.1


sql/examples/ha_archive.cc:
  Auto merged
This commit is contained in:
unknown
2005-01-28 18:10:47 -08:00
parent bc12f67343 96e4281f05
commit fa0b4b5e8d
2 changed files with 16 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
sql/examples/ha_archive.cc
View File

@ -42,18 +42,20 @@
handle bulk inserts as well (that is if someone was trying to read at
the same time since we would want to flush).
A "meta" file is kept. All this file does is contain information on
the number of rows.
A "meta" file is kept alongside the data file. This file serves two purpose.
The first purpose is to track the number of rows in the table. The second
purpose is to determine if the table was closed properly or not. When the
meta file is first opened it is marked as dirty. It is opened when the table
itself is opened for writing. When the table is closed the new count for rows
is written to the meta file and the file is marked as clean. If the meta file
is opened and it is marked as dirty, it is assumed that a crash occured. At
this point an error occurs and the user is told to rebuild the file.
A rebuild scans the rows and rewrites the meta file. If corruption is found
in the data file then the meta file is not repaired.
No attempts at durability are made. You can corrupt your data. A repair
method was added to repair the meta file that stores row information,
but if your data file gets corrupted I haven't solved that. I could
create a repair that would solve this, but do you want to take a
chance of loosing your data?
At some point a recovery method for such a drastic case needs to be divised.
Locks are row level, and you will get a consistant read. Transactions
will be added later (they are not that hard to add at this
stage).
Locks are row level, and you will get a consistant read.
For performance as far as table scans go it is quite fast. I don't have
good numbers but locally it has out performed both Innodb and MyISAM. For
@ -88,7 +90,6 @@
compression but may speed up ordered searches).
Checkpoint the meta file to allow for faster rebuilds.
Dirty open (right now the meta file is repaired if a crash occured).
Transactions.
Option to allow for dirty reads, this would lower the sync calls, which would make
inserts a lot faster, but would mean highly arbitrary reads.
@ -355,6 +356,7 @@ ARCHIVE_SHARE *ha_archive::get_share(const char *table_name, TABLE *table)
opposite.
*/
(void)write_meta_file(share->meta_file, share->rows_recorded, TRUE);
/*
It is expensive to open and close the data files and since you can't have
a gzip file that can be both read and written we keep a writer open
@ -401,6 +403,8 @@ int ha_archive::free_share(ARCHIVE_SHARE *share)
(void)write_meta_file(share->meta_file, share->rows_recorded, FALSE);
if (gzclose(share->archive_write) == Z_ERRNO)
rc= 1;
if (my_close(share->meta_file, MYF(0)))
rc= 1;
my_close(share->meta_file,MYF(0));
my_free((gptr) share, MYF(0));
}