Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread liviuslivius
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

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Nikolay Samofatov
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 we

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Nikolay Samofatov
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 R

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Carlos H. Cantu
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 severa

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Simonov Denis
Nikolay Samofatov писал(а) в своём письме 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 maintain >> compatibility.

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Dmitry Yemanov
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 sta

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Dimitry Sibiryakov
23.06.2014 21:15, Leyne, Sean wrote: > Actually, without the new behaviour, the engine results are not guaranteed to > be correct. And this is correct and predictable behaviour of TIL read committed. > There is no dilemma -- the engine must return consistent and correct results > **always**.

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Leyne, Sean
> 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

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Dmitry Kuzmenko
Здравствуйте! 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

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Nikolay Samofatov
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

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Nikolay Samofatov
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 intereste

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Nikolay Samofatov
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, n

[Firebird-devel] [FB-Tracker] Created: (CORE-4471) Allow to specify plugin authorization statement EXECUTE STATEMENT

2014-06-23 Thread Simonov Denis (JIRA)
Allow to specify plugin authorization statement EXECUTE STATEMENT - Key: CORE-4471 URL: http://tracker.firebirdsql.org/browse/CORE-4471 Project: Firebird Core Issue Type: Improv

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Dmitry Yemanov
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 (wit

Re: [Firebird-devel] Cursor stability in READ COMMITTED transactions

2014-06-23 Thread Vlad Khorsun
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 program