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

Engine could hang when working with read-only database [CORE3041] #3422

Closed
firebird-automations opened this issue Jun 13, 2010 · 7 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @hvlad

Commits: 579ffda 37a15c5

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

No sense to check in 2.1.x. No need to test for 2.5 and above because this bug can not occur there.

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Attachment and transactions ID's derived from values stored on header page.
In case of read-only database this values keeps in-memory and incremented as needed.
isc_database_info call leads to re-reading of header page and re-reading in-memory counterrs for next attachment and transaction IDs.
Therefore it is possible that some attachments\transactions will have the same ID's as some older attachments\transactions.
It leads to waiting of new attachment\transaction for the end of existing attachment\transaction with the same ID.
When waiting for attachment lock, global mutex is locked and old attachment can't even complete own disconnect and release attachment lock.
So, we have an endless deadlock. This is (deadlock) true for SuperServer. For Classic Server we will observe hang of some new attachment\transaction until existing attachment\transaction is alive.

v2.5 have no this bug as it derives new attachment\transaction ID from shared counter and it can't be reset by re-reading header page.

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

Hang of whole process of SuperServer is fixed.
More complete solution for CS is already implemented in v2.5

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.0.6 [ 10303 ]

Fix Version: 2.1.4 [ 10361 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @pmakowski

Confimed by user

@firebird-automations
Copy link
Collaborator Author

Modified by: @pmakowski

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: Cannot be tested

Test Details: No sense to check in 2.1.x. No need to test for 2.5 and above because this bug can not occur there.

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