> >>4) At startup, read-committed transactions also take a lock in the blob
> >>garbage collection series, identified by transaction id and containing
> >>the current oldest-active as the data portion.
> >
> >
> > What value snapshot transactions will put in this lock ? Zero ? Or its
> > will not take this lock at all ?
>
> Snapshot transactions won't take this lock at all.
>
> > If latter - why read-commited transactions
> > take usual transaction lock ?
>
> Because we need that lock to wait on when there's an update conflict.

Ok. But we have here a choice between two alternatives:

1. Snapshot transactions have one lock. Read-commited transactions
have two locks and they always put a zero in one of its lock data.
So we have substantial growth of lock count - twice in a worst case.
Note that half of this locks is useless as we can wait on any of
transaction locks. But we keep a simple code

2. Snapshot transactions have one lock. Read-commited transactions
also have one lock (in another series). When we need to wait on
transaction lock we need to check both lock series. Code is a more
complex but we don't grow locks amount.

What alternative a cheaper ? I don't know

Regards,
Vlad

PS I think garbage collector's transaction (and sweep's one) must
put a zero in a both locks as it never reads a commited blobs
and must not block garbage collection too, isn't it ?