Hi, all!
My 2 cents. Current behavior is really a BUG and I cannot imagine who
wants to have such logically incorrect data. It's enough for me to
make a conclusion to have new behavior as default. Some developers who
really understand that such situation cannot happen in his system can
EXPLICITLY
On 06/24/14 22:22, Dmitry Yemanov wrote:
> 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.
>
This GC blockage will definitely cause performance problems. It's
unavoidab
On 06/24/14 20:05, Dimitry Sibiryakov wrote:
> 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_
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
---
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 mana
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 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 isc
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
<>
Exactly... 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.
Regards
Paul Beach
Tel (France): +33 (0) 2 47 58 30 43
Mob (France): +33 (0) 6 79 24 32 32
-
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
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 d
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 adverti
> 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
13 matches
Mail list logo
