28.03.2014 17:43, Dimitry Sibiryakov wrote:
Either I don't understand something or garbage_collect_idx() doesn't do
what it is
supposed to do.
I've found the problem. Global variables must die. Only miracle prevents
this piece of
code from crash:
undo =
29.03.2014 14:21, Dimitry Sibiryakov wrote: Because this call uses
(relatively)
global record buffer, content of 'old_data' is
replaced with 'undo', so the data that should go is wrong.
Just as a note: even if this side effect is fixed, the logic of
verb_post()/grabage_collect_idx()
Poor performance of updating when use explicit cursor
-
Key: CORE-4379
URL: http://tracker.firebirdsql.org/browse/CORE-4379
Project: Firebird Core
Issue Type: Bug
Components:
A definite sequence of 'release savepoint' + 'rollback to savepoint'
can lead to missing entries.
And you have a sample, of course ?
Regards,
Vlad
--
Firebird-Devel mailing list, web interface at
28.03.2014 17:43, Dimitry Sibiryakov wrote:
Either I don't understand something or garbage_collect_idx() doesn't do
what it is
supposed to do.
I've found the problem. Global variables must die. Only miracle prevents
this piece of
code from crash:
undo =
29.03.2014 19:41, Vlad Khorsun wrote:
And you have a sample, of course ?
I have sample, of course, but it doesn't produce any problem now, while
verb_post() is
broken.
--
WBR, SD.
--
Firebird-Devel
29.03.2014 23:06, Vlad Khorsun wrote:
Record buffer is cached at the transaction level and exists in single
instance. It is OK
while we use just one instance of record buffer at the same time.
What is meant here by record buffer -- tra_undo_record or what?
Dmitry
Record buffer is cached at the transaction level and exists in single
instance. It is OK
while we use just one instance of record buffer at the same time.
What is meant here by record buffer -- tra_undo_record or what?
tra_undo_record, of course
Regards,
Vlad
