We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Submitted by: Andreas Rosenbaum (anros)
Jira_subtask_outward CORE2236
Attachments: core-1801.zip
Sweep can take a long time after updating the same record many times while another transaction was open.
Steps to reproduce:
create table testtable ( pk integer not null, dtvalue date );
alter table testtable add constraint pk_testtable primary key (pk); create index idx_dtvalue on testtable (dtvalue);
insert into testtable(pk, dtvalue) values (1, current_timestamp);
2) open transaction 1
open transaction 2 "update testtable set dtvalue = current_timestamp where pk = 1;" commit transaction 2 repeat step 3 100.000 times
4) commit transaction 1
select * from testtable
Result: fbserver uses 100% CPU for several minutes (up to several hours when adding more columns and indizes to testtable)
The problem does not occur without index "idx_dtvalue" or with firebird 1.5.3
The text was updated successfully, but these errors were encountered:
assignee: Vlad Khorsun [ hvlad ]
Sorry, something went wrong.
Commented by: @hvlad
Can't reproduce.
Test application
Attachment: core-1801.zip [ 10910 ]
Should we close this ticket as non-reproducible ?
Commented by: @dyemanov
Vlad, isn't it the issue we already discussed privately, at least twice? I mean very ineffective logic in list_staying().
Dmitry, i see no direct relation between this (not reproducible) issue and known weakness of list_staying.
Especially as Andreas see no problem : > without index "idx_dtvalue" or with firebird 1.5.3
As for list_staying() we could create improvement request ;)
hvlad
No branches or pull requests
Submitted by: Andreas Rosenbaum (anros)
Jira_subtask_outward CORE2236
Attachments:
core-1801.zip
Sweep can take a long time after updating the same record many times while another transaction was open.
Steps to reproduce:
1) Preparation
create table testtable
(
pk integer not null,
dtvalue date
);
alter table testtable add constraint pk_testtable primary key (pk);
create index idx_dtvalue on testtable (dtvalue);
insert into testtable(pk, dtvalue)
values (1, current_timestamp);
2) open transaction 1
3) update record
open transaction 2
"update testtable set dtvalue = current_timestamp where pk = 1;"
commit transaction 2
repeat step 3 100.000 times
4) commit transaction 1
5) trigger sweep
select * from testtable
Result: fbserver uses 100% CPU for several minutes (up to several hours when adding more columns and indizes to testtable)
The problem does not occur without index "idx_dtvalue" or with firebird 1.5.3
The text was updated successfully, but these errors were encountered: