10.05.2014 14:50, Vlad Khorsun wrote: > Explain, please, because i see no way to use undo log (which is > maintained in > memory for *currently* active tx) for garbage collection of record chain > which primary > version was created by *another* tx.
It is not needed because blob id is a physical address of blob and cannot be reused until the blob is garbage collected. Blob cannot be garbage collected while at least one on-disk version is referring it. Version of a record before any active transaction cannot be garbage collected because the transaction can be rollbacked. If update-in-place change blob field, it will get new blob id, completely different from all staying ids. Even if you changed blob value forth and back, blob id will be new, different one. That's why GC of any old blob id won't destroy new blob. Because of all this, maximum three record versions are enough for decision whether blob can be GC-ed or not. Example: version 1 on disk with blob id 1 - garbage version 2 on disk with blob id 2 - garbage version 3 on disk with blob id 2 - still active version 4 in memory with blob id 3 - potentially active version 5 on disk with blob id 4 - uncommitted Blob id 1 can be garbage collected, but blob id 2 cannot because version 3 referring it. Versions 3 and later under any circumstances cannot have blob id 1 because it is still allocated. Even if "update set blob_field=1" is performed, content of blob with id 1 will be copied and new version will get new blob id. When savepoint with version 4 is gone, blob 3 can be garbage collected because neither previous nor following version use it and rollback to this savepoint is not possible after its release, so there cannot be active record referring blob id 3. In short: blob id which going version is referring to can cleaned only if it is not referred by both previous or next versions. All other versions are irrelevant because they cannot refer the same blob id. At least in current codebase which creates a new copy of blob content on update. -- WBR, SD. ------------------------------------------------------------------------------ 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
