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

Execution of SET STATISTICS INDEX statement could block or slow execution of concurrent attachments [CORE4215] #4540

Closed
firebird-automations opened this issue Sep 11, 2013 · 14 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @hvlad

Votes: 2

BTR_selectivity() walks the whole leaf level of given index b-tree to calculate index selectivity.
During whole process rescheduling points in the engine happens only at disk IO operations.
Therefore concurrent attachment's AST requests such as page lock requests, monitoring,
cancellation, etc could wait too long.

Commits: dd5b5af cfa78a3 FirebirdSQL/fbt-repository@648fe03 FirebirdSQL/fbt-repository@d0d0174

====== Test Details ======

Creation of huge table on the fly is not allowed - we can not waste time for this while all tests running.
Database with huge table should be preliminary created (seperately for every ODS) and committed on test running host.
It seems to me that this is also undesirable.
Waiting for other suggestions how to implement such test.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

description: BTR_selectivity() walks the whole leaf level of given index b-tree to calculate index selectivity.
During whole process there is no resheduling points in the engine. It block's concurrent
attachment's AST requests such as page lock requests, monitoring, cancellation etc.

=>

BTR_selectivity() walks the whole leaf level of given index b-tree to calculate index selectivity.
During whole process rescheduling points in the engine happens only at disk IO operations.
Therefore concurrent attachment's AST requests such as page lock requests, monitoring,
cancellation, etc could wait too long.

summary: Execution of SET STATISTICS INDEX statement could block execution of concurrent attachments => Execution of SET STATISTICS INDEX statement could block or slow execution of concurrent attachments

@firebird-automations
Copy link
Collaborator Author

Commented by: Siva Ramanathan (s2ramana)

This is a serious issue for any 24x7 sites using Firebird.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Siva,
Could you confirm the issue is solved or not, please ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Siva Ramanathan (s2ramana)

Vlad,

IBPhoenix is preparing a build for us with the fix. We should be receiving the build any day now. Once we receive the build, we will test it out and give our feedback.

Regards,
Siva

@firebird-automations
Copy link
Collaborator Author

Commented by: @paulbeach

Siva,

Vlad was the developer we worked with on this issue. Your current build has the fix for this issue. The new build addresses another problem.

Paul

@firebird-automations
Copy link
Collaborator Author

Commented by: Siva Ramanathan (s2ramana)

Paul,

Thanks for the update.

Regards,
Siva

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Any feedback ?

@firebird-automations
Copy link
Collaborator Author

Commented by: Siva Ramanathan (s2ramana)

Vlad, your fix appears to be working correctly. We have not noticed this issue after applying the fix.

Regards,
Siva

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Siva,

will close it as fixed, thanks

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5.3 [ 10461 ]

Fix Version: 3.0 Alpha 2 [ 10560 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Deferred

Test Details: Creation of huge table on the fly is not allowed - we can not waste time for this while all tests running.
Database with huge table should be preliminary created (seperately for every ODS) and committed on test running host.
It seems to me that this is also undesirable.
Waiting for other suggestions how to implement such test.

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