Thanks, Ann, now I understand. Then I guess I have no choice but to
periodically shut down my daemon so I can backup the database file.

Periodic maintenance is not too bad! I can live with it until FB2.0
become a release product, I can then use the "alter database
begin/end.." stmt to backup the database on the fly.

Jeff
--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> Jeff Lynn wrote:
> > OK, Thanks! I am not ready to move on to FB 2.0 yet. So from what I
> > gathered from all the postings, as long as I used my semaphore to
> > regulate access to the embedded database file, then a file copy will
> > work as all hard-drive caching will be flushed out to the actual drive
> > when file copy takes place? Did I interpreted that right?
>
> Not quite. Normally, when file caching is enabled, read and write
> requests are satisfied from the cache without going to disk at all.
> When forced writes are enabled, writes go through the cache to disk
> directly, but the updated version of the page stays in cache and
> reads continue to be served from the cache. Either way, your reads
> will see the most recent version of data.
>
> The problem that can occur is the independent garbage collect
> thread. When a transaction finds a record version that is no longer
> useful to any other transaction, it puts that record version on a
> list for removal. Some time later, a special garbage collect thread
> reads the list and removes the old version. That operation can
> affect more than one page, but it's done in an order that minimizes
> the effect of the change on concurrent operations - but doesn't
> solve the copy problem.
>
> Specifically, when an old record version is removed, the garbage
> collector first zeros the pointer from the new record version to
> the old. It then goes to the page with the old record version.
> The page, like all data pages, has an index of the offset and
> length of records, record versions, fragments, and blobs on the
> page. The garbage collect thread sets the length and offset of
> the old record version to zero.
>
> So, what happens if your copy happens to pick up half of a
> garbage collection operation? If the new record is on page
> 100 and the old version is on page 10000, there's a chance
> that the garbage collector will change both those pages
> after you've read page 100 with the old back pointer and
> before you read page 10000. Your copy will have an invalid
> back pointer.
>
> Is that the end of the world? Maybe not. Running gbak with
> the -g switch should allow you to create a valid backup of
> your invalid copy, which you can restore and create a valid
> logical copy.
>
> Regards,
>
>
> Ann
>