summaryrefslogtreecommitdiff
path: root/sql/examples
diff options
context:
space:
mode:
authorunknown <monty@mysql.com>2005-02-03 13:18:30 +0200
committerunknown <monty@mysql.com>2005-02-03 13:18:30 +0200
commit4f1cbb6031d8310f17db9e503234ef169805412a (patch)
treee52c0cca0b1936bb8b6332b6f0e724b9666f65f1 /sql/examples
parent9240144b739dda5b1221b880f9bade0f774697e6 (diff)
parentad21db5e0727704ee0527c08410bafff4d3150f4 (diff)
downloadmariadb-git-4f1cbb6031d8310f17db9e503234ef169805412a.tar.gz
4.1 -> 5.0 merge
BitKeeper/etc/logging_ok: auto-union Build-tools/Do-compile: Auto merged client/mysqladmin.cc: Auto merged client/mysqldump.c: Auto merged configure.in: Auto merged extra/perror.c: Auto merged innobase/buf/buf0rea.c: Auto merged innobase/fil/fil0fil.c: Auto merged innobase/include/rem0rec.ic: Auto merged innobase/include/univ.i: Auto merged innobase/os/os0file.c: Auto merged innobase/ut/ut0ut.c: Auto merged mysql-test/r/derived.result: Auto merged mysql-test/r/func_str.result: Simple merge mysql-test/r/subselect.result: Automatic merge mysql-test/t/derived.test: Automatic merge mysql-test/t/func_str.test: Simple merge mysql-test/t/subselect.test: Automatic merge mysys/my_handler.c: Automatic merge ndb/src/kernel/blocks/backup/Backup.cpp: Automatic merge scripts/make_binary_distribution.sh: Automatic merge scripts/mysql_install_db.sh: Automatic merge sql/examples/ha_archive.cc: Simple merge sql/ha_innodb.cc: Automatic merge sql/item.cc: Merge sql/item_cmpfunc.h: Automatic merge sql/item_func.cc: Simple merge sql/item_func.h: Automatic merge sql/item_strfunc.cc: Automatic merge sql/item_strfunc.h: Automatic merge sql/item_subselect.cc: Automatic merge sql/mysqld.cc: Automatic merge sql/set_var.cc: Automatic merge sql/sql_base.cc: Automatic merge sql/sql_class.cc: Automatic merge sql/sql_class.h: Automatic merge sql/sql_lex.cc: Automatic merge sql/sql_lex.h: Automatic merge sql/sql_parse.cc: Automatic merge sql/sql_select.cc: Automatic merge sql/sql_table.cc: Automatic merge sql/sql_update.cc: Simple merge strings/ctype-big5.c: Automatic merge strings/ctype-bin.c: Automatic merge strings/ctype-gbk.c: Automatic merge strings/ctype-latin1.c: Automatic merge strings/ctype-mb.c: Automatic merge strings/ctype-simple.c: Automatic merge strings/ctype-sjis.c: Automatic merge strings/ctype-tis620.c: Automatic merge strings/ctype-ucs2.c: Automatic merge strings/ctype-utf8.c: Automatic merge vio/viosocket.c: Automatic merge vio/viossl.c: Automatic merge
Diffstat (limited to 'sql/examples')
-rw-r--r--sql/examples/ha_archive.cc27
1 files changed, 15 insertions, 12 deletions
diff --git a/sql/examples/ha_archive.cc b/sql/examples/ha_archive.cc
index 436c72702a0..b33b5102e69 100644
--- a/sql/examples/ha_archive.cc
+++ b/sql/examples/ha_archive.cc
@@ -43,18 +43,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
@@ -89,7 +91,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.
@@ -347,6 +348,7 @@ ARCHIVE_SHARE *ha_archive::get_share(const char *table_name, TABLE *table)
share->crashed= TRUE;
else
(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
@@ -393,7 +395,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;
- my_close(share->meta_file,MYF(0));
+ if (my_close(share->meta_file, MYF(0)))
+ rc= 1;
my_free((gptr) share, MYF(0));
}
pthread_mutex_unlock(&archive_mutex);