> 10.05.2014 15:30, Vlad Khorsun wrote:
>> Here you wrong: if blob contents was not changed by update, there will
>> be no new blob.
>
> Yes, and in this case blob cannot be garbage collected because next record
> version
> refers to it. No need to analyze whole versions chain (collect staying list)
> - two these
> versions are enough for decision making. (Actually, there must be three
> versions for
> analyze, but one of them may be missed if going version is on the end of
> chain.)
It is wrong for "lost update" scenario, which is allowed for read-committed
transactions:
att1: start tx1, insert version1 (blob1), commit tx1
att1: start tx2 (read-committed), read version1 (blob1)
att2: start tx4, update version2 (blob2), commit tx4
att1: update version3 (blob1), commit tx2
Here we have chain of versions:
version3 (tx2, blob1) -> version2 (tx4, blob2) -> version1 (tx1, blob1)
Regards,
Vlad
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
