Skip to content
New issue

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

Sweep can take a long time at 100% CPU [CORE1801] #2228

Open
firebird-automations opened this issue Mar 25, 2008 · 7 comments
Open

Sweep can take a long time at 100% CPU [CORE1801] #2228

firebird-automations opened this issue Mar 25, 2008 · 7 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Can't reproduce.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Test application

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

Attachment: core-1801.zip [ 10910 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Should we close this ticket as non-reproducible ?

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Vlad, isn't it the issue we already discussed privately, at least twice? I mean very ineffective logic in list_staying().

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment