Denis, On 06/21/2014 08:10 AM, Simonov Denis wrote: > A long-running transaction READ READ_COMMITED will not keep the garbage? > Maybe we should introduce a new key TPB, if you want to maintain > compatibility.
Yes, for READ_ONLY + READ COMMITTED transactions you will now inhibit GC if you keep a cursor open for a long time. I believe that engine shall strive to do "the right thing" and pay the cost if necessary. Otherwise you won't really know what data will be returned to you, and it will change based on the query plan chosen by the optimizer this time (if SORT was used, etc). This can be confusing and damaging, if somebody depends on this data. And if you want compatibility - please use compatibility configuration setting until you fix your application to accommodate for changed behavior. I refer this to Dmitry, but I think that we shall correct MON$TRANSACTIONS to return GC watermark in MON$OLDEST_ACTIVE rather than oldest snapshot number. Otherwise it mismatches INF interface where GC watermark is returned in isc_info_tra_oldest_active, and isc_info_tra_oldest_snapshot returns oldest snapshot number. Oldest snapshot number is the implementation detail of GC algorithm and is mostly useless for users. But GC watermark is really interesting, if you want to find out which transaction inhibits your GC. Currently, to monitor this counter you need to use fb_lock_print, and this is not convenient at all. Nikolay Samofatov ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
