This is what I sent to the postgres list.

>Date: Fri, 16 Jan 2004 11:14:07 -0500
>From: Ann Harrison <aharrison@...>
>To: pgsql-general@...
>Subject: [GENERAL] serverless postgres, embedded firebird, etc.
>
>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 majordomo@...)

Regards,

Ann
www.ibphoenix.com
We have answers.