All, On 06/23/2014 03:26 PM, Dmitry Yemanov wrote: > 23.06.2014 23:15, Leyne, Sean wrote: >> Actually, without the new behaviour, the engine results are not guaranteed >> to be correct. > But the point is that their "correctness" depends on the application > logic. Lots of applications using RC RO transactions will never be > affected by the cursor stability issue. But they will be paying the cost.
It is hard to call internally inconsistent result "correct". Just imagine you perform a SELECT query with a few left joins, or EXISTS clause. Some records for a join can be read before a transaction is committed, and some after. Same with EXISTS. It can see different set of commits from the one when main row was read. You can see partial commits in results, even inside a single row returned by the query. Nobody is ready for this, this is CRAZY, nobody expects this. If this data is used for any remotely important purpose, you will get whammed. The fact that inconsistency shows up infrequently, under parallel load and is not easily reproducible, sets you up to be eventually burned. And once burned you will hesitate to trust DMBS that behaves in such ways. This is not normal. This is a BUG. Nikolay ------------------------------------------------------------------------------ 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
