Re: [Firebird-devel] Firebird Transaction ID limit solution

[Ann H. <aha...@nu...>]

Woody,

> Maybe I'm a little dense, (probably :), but doesn't FB already know what the
> oldest interesting transaction id is? Why couldn't transaction numbers be
> allowed to wrap back around up to that point? As long as transactions are
> committed at some point, the oldest transaction would move and it would
> solve most problems being run into now.

The oldest interesting transaction is the oldest on that is not known
to be committed.  If  the oldest interesting transaction is 34667, and
you're transaction 55778, you know that anything created by
transaction 123 is certain to be committed.

Now lets assume that you're transaction 4294967000 and the oldest
interesting transaction was 4294000000 when you started.  (Probably
ought to mention that (IIRC) a transaction picks up the value of its
the oldest interesting on startup).  Then the transaction counter
rolls around and some new transaction 3 starts creating new
versions...  You know they're committed, so you read the new data.

More generally, how do you know the difference between the old
transaction 3 record versions which you do need to read and new new
transaction 3 records that you don't want to read?

> I will accept any and all ridicule if this seems idiotic ...

Not at all idiotic.  This stuff is complicated.


Cheers,

Ann