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

[firebird-issue-importer]

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-issue-importer]

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

[firebird-issue-importer]

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-issue-importer]

Commented by: @hvlad

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

[firebird-issue-importer]

Modified by: @hvlad

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

resolution: Fixed [ 1 ]

Fix Version: 2.0.6 [ 10303 ]

Fix Version: 2.1.4 [ 10361 ]

[firebird-issue-importer]

Commented by: @pmakowski

Confimed by user

[firebird-issue-importer]

Modified by: @pmakowski

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

[firebird-issue-importer]

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.