You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.