Hi,
i try to follow this discussion and try to understand it.
Is this discussion only about Read-only RC or about all RC transactions?
If i understand correctly this bug it look like (correct me if i am wrong):
SELECT
(SELECT COUNT(*) FROM TEST T2 WHERE T2.SOME_FIELD=1) /* Query 2 */
FROM
TEST
i try to follow this discussion and try to understand it.
Is this discussion only about Read-only RC or about all RC transactions?
It is only about READ-ONLY + READ COMMITTED.
Sean
--
Open source business process
Hi,
At June 23, 2014, 4:19 PM, Carlos H. Cantu wrote:
NS Yes, for READ_ONLY + READ COMMITTED transactions you will now
NS inhibit GC if you keep a cursor open
NS for a long time.
This is serious change, and I'm probably against it being the default
behavior. So far, it is well advertised
23.06.2014 21:57, Nikolay Samofatov wrote:
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.
Shouldn't data
24.06.2014 17:35, Daniel Rail wrote:
I don't think it takes out the non-blocking behavior, because the
blocking is only performed at the statement level, not the transaction
level. So, for a lookup dataset, it would not change a thing, since
the query results will always pick up committed
But, after reading MS-SQL's read committed isolation level, their
default behavior is the same as Firebird's. And, they introduced the
READ COMMITTED SNAPSHOT isolation level, which is at the statement
level, and that is what Nickolay is looking for. And, both READ
COMMITTED isolation levels fall
Hi,
At June 24, 2014, 12:45 PM, Dmitry Yemanov wrote:
24.06.2014 17:35, Daniel Rail wrote:
I don't think it takes out the non-blocking behavior, because the
blocking is only performed at the statement level, not the transaction
level. So, for a lookup dataset, it would not change a thing,
24.06.2014 17:53, Paul Beach wrote:
we need to keep our default behaviour as is and
create a new isolation level that supports the cursor stability
in Read Committed that Nikolay wants.
I would rather vote for a TPB flag like
isc_tpb_insensitive_cursor/sensitive_cursor. It
would fit
24.06.2014 01:33, Nikolay Samofatov wrote:
If this is what people want, it is possible to add new TPB parameter -
isc_tpb_inconsistency, and
permit it for READ_ONLY + READ COMMITTED transactions only. For as long you
don't use returned data
for anything important it is somewhat safe.
24.06.2014 22:12, Dmitry Yemanov wrote:
(*) AFAIU, there's no other practical benefit in the sensitive mode
except the performance.
And the GC blockage in RC RO txns.
Dmitry
--
Open source business process
I'm trying to download the Windows FB 3 snapshots, but the link is
offline:
http://web.firebirdsql.org/download/snapshot_builds/win/
Can someone fix it or send me the lastest build?
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
11 matches
Mail list logo
