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-issue-importer opened this issue Sep 11, 2013 · 14 comments

Comments

@firebird-issue-importer

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 11, 2013

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 11, 2013

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 11, 2013

Commented by: Siva Ramanathan (s2ramana)

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 29, 2013

Commented by: @hvlad

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 30, 2013

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 30, 2013

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 30, 2013

Commented by: Siva Ramanathan (s2ramana)

Paul,

Thanks for the update.

Regards,
Siva

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 10, 2013

Commented by: @hvlad

Any feedback ?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 10, 2013

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 10, 2013

Commented by: @hvlad

Siva,

will close it as fixed, thanks

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Dec 10, 2013

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-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Sep 22, 2015

Modified by: @pcisar

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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 18, 2016

Modified by: @pavel-zotov

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

QA Status: No test

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Aug 21, 2016

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