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
unavoidable.
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/25/14 10:49, Roman Simakov wrote:
Hi, all!
My 2 cents. Current behavior is really a BUG and I cannot imagine who
wants to have such logically incorrect data.
A sample.
Warehouse has a number of workplaces with computers for shipping goods.
At some workplace in the beginning of a day
2014-06-25 11:24 GMT+04:00 Alex Peshkoff peshk...@mail.ru:
A sample.
Warehouse has a number of workplaces with computers for shipping goods.
At some workplace in the beginning of a day were shipped some antennas,
books and computers. I.e. we are at the top of the grid, cursor is
opened but
Roman Simakov roman.sima...@gmail.com wrote Wed, 25 Jun 2014 10:49:01
+0400:
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
On 06/25/14 11:52, Roman Simakov wrote:
2014-06-25 11:24 GMT+04:00 Alex Peshkoff peshk...@mail.ru:
A sample.
Warehouse has a number of workplaces with computers for shipping goods.
At some workplace in the beginning of a day were shipped some antennas,
books and computers. I.e. we are at the
25.06.2014 11:52, Roman Simakov wrote:
present at the opening cursor. IMO it's bad style to open cursor. It
may keep open transaction (it's also not good but RO+RC possible) but
it should not keep open cursor. I do not understand why to open cursor
at all if you are not going to fetch right
25.06.2014 9:52, Roman Simakov wrote:
2014-06-25 11:24 GMT+04:00 Alex Peshkoff peshk...@mail.ru:
please answer what quantity of them do we prefer to see - current or
present at the beginning of a day?
present at the opening cursor.
In this case why to use READ COMMITED transaction at
2014-06-25 12:09 GMT+04:00 Dimitry Sibiryakov s...@ibphoenix.com:
In this case why to use READ COMMITED transaction at all?..
Because opening cursor is not opening transaction. You can have long
transaction but not opened cursors. Do not open if you are not going
to fetch.
--
Roman Simakov
25.06.2014 11:46, Roman Simakov wrote:
2014-06-25 12:09 GMT+04:00 Dimitry Sibiryakov s...@ibphoenix.com:
In this case why to use READ COMMITED transaction at all?..
Because opening cursor is not opening transaction. You can have long
transaction but not opened cursors. Do not open if you
On 06/25/14 13:49, Mark Rotteveel wrote:
I just saw this commit
https://github.com/asfernandes/firebird/commit/23072a0d77e8a6c2b4972800d31285e96fa28dd8
This commit replaces (apparently) incorrect uses of a constant with a
magic value. Can I suggest that this is either reverted, or replaced
2014-06-25 13:52 GMT+04:00 Dimitry Sibiryakov s...@ibphoenix.com:
I.e. a strange application developer start transaction, then, after some
time, start a
query and want to see data consistent to the moment of query start instead of
transaction
start?
Exactly. The same prepared query can
Message Modifying function F which is currently in use when running script
with AUTODDL=OFF and F is called from INTERNAL function declared in other unit
25.06.2014 12:41, Roman Simakov wrote:
The same prepared query can re-read fresh data in the same
transaction, for instance refresh number of books.
You'll be wondered, perhaps, but a prepared query can re-read fresh data in
any
transaction, not only in one where it was prepared.
But
On 25/06/2014 05:10, Dmitry Yemanov wrote:
25.06.2014 11:52, Roman Simakov wrote:
present at the opening cursor. IMO it's bad style to open cursor. It
may keep open transaction (it's also not good but RO+RC possible) but
it should not keep open cursor. I do not understand why to open cursor
2014-06-25 14:49 GMT+04:00 Dimitry Sibiryakov s...@ibphoenix.com:
25.06.2014 12:41, Roman Simakov wrote:
The same prepared query can re-read fresh data in the same
transaction, for instance refresh number of books.
You'll be wondered, perhaps, but a prepared query can re-read fresh data
On 06/25/14 15:14, Adriano dos Santos Fernandes wrote:
On 25/06/2014 05:10, Dmitry Yemanov wrote:
25.06.2014 11:52, Roman Simakov wrote:
present at the opening cursor. IMO it's bad style to open cursor. It
may keep open transaction (it's also not good but RO+RC possible) but
it should not
25.06.2014 15:28, Alex Peshkoff wrote:
The problem with RC+RO consistent transaction blocking GC may be gone if
the engine runs the query till the end and store it in temporary buffer.
Dmitry, is this (more or less) what is already done to support
bidirectional cursors?
Yes, but this is
25.06.2014 13:13, Roman Simakov wrote:
Explain it to strange developers who start transaction and open
cursor at the begin of day in order to fetch at the end :)
And one more about logic. Currently it's possible:
1) We have a table X(c char) with 2 records {A, B}
2) transaction T1 opens
I suggest you investigate garbage collecting intermediate
unreachable record versions, which would completely take the sting out of
long running transactions. It's not difficult for superserver, but would
be problematic for classic. But I don't think that in itself is a problem.
I have never
All,
On 06/25/2014 09:41 AM, James Starkey wrote:
I suggest you investigate garbage collecting intermediate unreachable record
versions, which would
completely take the sting out of long running transactions. It's not
difficult for superserver,
but would be problematic for classic. But
Different gdscode in 3.0 vs 2.5 when lock conflict occurs
-
Key: CORE-4473
URL: http://tracker.firebirdsql.org/browse/CORE-4473
Project: Firebird Core
Issue Type: Bug
Affects
AFAIK, concurrent GC in pre-committed transactions without transaction lock
was unsafe, and created
permanently broken databases.
I believe corruption has become especially apparent after commit intended to
fix CORE-3515. I don't
know who fixed it, but Red Soft builds include a patch for
23 matches
Mail list logo
