Tom,
Actually, I've never had a corrupted firebird database. There were
two bugs in an older version of InterBase that produced income for me.
The first was a failure to realize that a file had just gone over 4Gb
and therefore the word holding the offset had rolled over and the system
had begun writing at the beginning of the file. Nasty. The second was
a case that allowed a server to open a single database twice, thinking
it was two different databases. That lead to doubly allocated pages
which lead to wrong page types, etc. Both problems were fixed before
the first version of firebird shipped.
On the larger question of embedded database code, yes, there is
certainly the possibility of user data overwriting database data
structures, accidentally or intentionally. The intentional part is a
question for the builders and users of the application. Only trusted
programs should ever run with an embedded engine. The accidental part
rarely, if ever corrupts a database for two reasons.
First, there's quite a lot of checking internally. A trashed data
structure is recognized quickly and shuts down the connection without
writing anything. Reestablishing the connection creates an entirely new
set of internal structures, disposing of the corruption.
Second, the database is always (in almost all circumstances)
consistent, even if uncommitted data must be written. Our goal, from
the beginning, was to allow the database to restart instantly from a
crash caused by tripping over the power cord of the server. It works,
except in one actual and one theoretic case.
We offer an asynchronous write mode because flushing files on Unix
systems is too expensive. (The system was originally written for VMS,
which didn't have a page cache.) On Unix systems, the careful write is
almost always successful enough even asynchronously because pages
aren't kept in the system cache for long. That's the theoretic case.
The actual case is on windows which, by default, keeps pages in cache
until process shutdown. Pulling the plug on a windows system that's
using asynchronous writes is the actual problem.
Fortunately, people have learned not to run power cords from their
servers across corridors and such, so the "tripped over the power cord"
problem is much reduced from years past. However, in areas with
frequent power failures, there are occasional broken databases caused by
pages that were in the cache and not written. Generally, that happens
in less developed countries where the cost of a UPS is significant.
Needless to say, the cost of having me repair the database is also
significant. Often, after the user pleads and grovels on the subject of
not having a UPS or a database backup, I fix those for free. Harrison's
campaign for world harmony. Don't tell my boss.
Firebird and InterBase have been used in "embedded" mode since 1985
and don't seem to corrupt data except in the cases described above. The
next version of Firebird also forces Windows to flush its cache
regularly, which should be a boon for our Latin American users.
Best regards,
Ann
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
