> Ann W. Harrison wrote:

...

Excellent explain of current state of things !

> So, suppose we add another lock series, just to hold the blob limit
> value for read-committed transactions. Those transactions would put a
> minus one in the lock data for their transaction lock and take out
> another lock in the new series. That lock would contain the transaction
> id of the oldest transaction currently running. When computing garbage
> collection limits, the engine queries both lock series, taking the GC
> Limit from the transaction locks and the BLOB Limit from the new series.

Hmm, why do you want to change behavior of current transaction lock data ?
As i understand we agreed that "read commited write" transactions must store
its own transaction number in its lock data (instead of found during TRA_start
oldest active number) ?

> When a read-committed transaction does a commit-retaining (or rollback
> retaining), it creates a new transaction lock block with a minus one for
> lock data,

The same question as above

> but retains the lock it has in the new series.

Agreed

> Thus blob-ids
> would be reliable across a commit-retaining, which makes sense to me,
> since the general description is that a commit-retaining "retains the
> context" of the transaction.

Of course

> We eliminate the current "pre-committed" status for read-only read
> committed transactions - it causes "blob not found" errors.

Do you want to delete "pre-committed" status from the engine ?

> This technique makes blob retrieval reliable for all read committed
> transactions (fixing a bug) and keeps all read committed transactions
> from block most garbage collections. In short, it's better than what
> InterBase is doing, and it works.
>
> At least, I think it works.

I want to think the same

Regards,
Vlad