21.06.2014 0:52, Nikolay Samofatov wrote:
Hello, All!
We have encountered subtle errors and data corruptions when using complex
triggers/stored procedures in READ COMMITTED
transactions.
I assume you tell about logical data corruptions, not physical, correct ?
Most applied programmers
21.06.2014 01:52, Nikolay Samofatov wrote:
I attach patch for this functionality to give you an idea of
implementation. It depends on a couple other changes so it doesn't apply
to FB2.5 cleanly.
The first thing I'm interested in is the performance impact in OLTP
tests similar to TPCC (with
Allow to specify plugin authorization statement EXECUTE STATEMENT
-
Key: CORE-4471
URL: http://tracker.firebirdsql.org/browse/CORE-4471
Project: Firebird Core
Issue Type:
Vlad,
On 06/23/2014 03:11 AM, Vlad Khorsun wrote:
21.06.2014 0:52, Nikolay Samofatov wrote:
Hello, All!
We have encountered subtle errors and data corruptions when using complex
triggers/stored procedures in READ COMMITTED
transactions.
I assume you tell about logical data corruptions,
Hello, Dmitry!
On 06/23/2014 04:15 AM, Dmitry Yemanov wrote:
21.06.2014 01:52, Nikolay Samofatov wrote:
I attach patch for this functionality to give you an idea of
implementation. It depends on a couple other changes so it doesn't apply
to FB2.5 cleanly.
The first thing I'm interested in is
Здравствуйте!
Monday, June 23, 2014, 10:31:57 PM, you wrote:
NS Denis,
NS 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.
NS Yes, for
NS Yes, for READ_ONLY + READ COMMITTED transactions you will now
NS inhibit GC if you keep a cursor open for a long time.
nice (sarcazm). So, dilemma is to enable your behavior, and get versions
stall,
or get versions not stalled by GS by usual RC Read?
Actually, without the new
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
Nikolay Samofatov nikolay.samofa...@red-soft.biz писал(а) в своём письме
Mon, 23 Jun 2014 22:31:57 +0400:
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
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 that transactions using RC+RO
does NOT block GC, and several
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
Hello, Carlos!
On 06/23/2014 03: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
12 matches
Mail list logo
