Re: Patch for bug#42208

[Ann W. Harrison]

Jim Starkey wrote:

> 
> One way around this is to put transaction id in the index.  This has 
> loads of problems:
> 
>    * Transaction ids aren't persisted across server invocations

Yup, if you store transaction id's in the database, they need to be
persistent.  And, sadly, 32 bit transaction ids are no longer
retirement proof.

>    * All versions of a record would need to reflected in the index

I don't think so.

>    * A record update that didn't change the index would still require
>      changing the transaction in the index

I don't think so.
> 
> Monty planned to do this with Maria

And here's how he explained it to me - at least as I remember it.
The header for an index entry has a state variable that indicates
that it is followed by

   a) the inserting transaction id.
   b) the removing transaction id.
   c) both.
   d) neither.

The inserting transaction id is present for newly inserted keys that
may not be visible to all running transactions.  The removing
transaction id is present if there are running transactions that
can still see the value, even though it as been removed.  If an
index entry is newer than the oldest active transaction and has
been removed, it will have both values.  If an entry is mature,
meaning that all active transactions can see it, it has no transaction
id.

There is no need to store index entries if the index key doesn't
change.  The index still points to the "master" version of the
record, which may not have the key value for any particular entry -
entries may represent older versions of the record and require
walking the record chain to verify their values.

There is a small question of index volatility.  I think the
intention was to keep some visibility rules - as our scavenger
does - and apply them to each index page before writing it.
If an entry is mature, then the inserting transaction id is
compressed out.  If the removal of an entry is mature, then
the whole thing goes away.

Or something like that.


Cheers,

Ann