> Vlad Horsun wrote:
> >
> I wrote:
> >>... for read-committed transactions. Those transactions would put a
> >>minus one in the lock data for their transaction lock ...
> >
> > 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) ?
>
> Ah. I've thought about it some more and decided I was wrong. A
> read-committed transaction should not block garbage collection at all,
> except to protect blobs.

During implementation of new transactions behavior and playing with what i got,
i found, unfortunately, that this is wrong and read-committed transactions must
store its own transaction number in its lock data.

Lets me explain what i found

> Consider this sequence
>
> Read committed transaction 101 starts
> Transaction 102 starts
> Transaction 102 writes record X
> Transaction 102 commits
> Transaction 103 starts
> Transaction 103 updates record X
> Transaction 103 commits
> Transaction 104 starts
> Transaction 104 reads record X
> ????
>
> Is there any reason why transaction 104 shouldn't remove the old record
> version stored by transaction 102? Transaction 102 won't read it - it
> will read the most recent committed version. Even record versions
> created after a read committed transaction started can be garbage
> collected without affecting running read committed transaction.

Transactions 102 - 104 all read-commited. Lets start snapshot
transaction and look what we get with it:

Tx 105 (read-committed) starts. It can remove committed versions below 105
Tx 106 (read-committed) starts. It can remove committed versions below 106
Tx 107 (snapshot) starts. It can't see versions created by tx 105 and 106

Tx 107 reads record Y by tx 100

Tx 105 updates record Y by tx 100
Tx 105 commits

Tx 106 reads record Y by tx 105 and removed record version by tx 100

Tx 107 can't read record Y as it created by tx 105 and have no
backversions

So, read-committed transactions must preserve record versions not
for another read-committed transactions but for future snapshot transactions.

Lets look at my example when read-committed transactions stored
its own numbers in transaction locks data:

Tx 105 (read-committed) starts. It can remove committed versions below 105
Tx 106 (read-committed) starts. It can remove committed versions below 105
Tx 107 (snapshot) starts. It can't see versions created by tx 105 and 106

Tx 107 reads record Y by tx 100

Tx 105 updates record Y by tx 100
Tx 105 commits

Tx 106 reads record Y by tx 105 and don't removed record version by tx 100
because main (top) record version is created by tx 105 which is not less
garbage collection threshold

Tx 107 can read record Y and still see version by tx 100

Regards,
Vlad