On 01/17/17 10:16, Dmitry Yemanov wrote: > Yet another case: > > Transaction creates a new format, stores some records using this new > format, then the server dies. After restart, changes in > RDB$FORMATS/RDB$RELATIONS are occasionally backed out. Then it could be > impossible to garbage collect the new record versions due to their > format being unknown. >
I can hardly imagine how can we avoid use of system transaction when modifying formats. Same for all cases related with allocation of special pages in database (like index creation) and creation of various files (external table, shadow, etc.). External file will not follow transaction commit or rollback :) That is the reason why we still modify that objects in tra_number == 0, and it does not matter is it done in DFW or using some other technique - in mentioned cases rdb$formats/rdb$pages/rdb$files should reflect reality around the table instead of our transaction rollback rules. BTW, all other tables in DFW are already modififed in user transaction. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
