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
"lock conversion denied" or "lock denied" error [CORE2848] #3234
Comments
Modified by: @hvladassignee: Vlad Khorsun [ hvlad ] |
Commented by: @ibprovider [03.12.2012 20:07:45] [info] Provider DLL :_IBProvider_v3_vc10_i.dll --------- [server log] HOME2 Mon Dec 03 21:48:49 2012 Source code of test: ibp_tso_octets_003_blobs.cpp -------- [thread #2] -------- [thread #6] deadlock Validation of database not find any errors. |
Commented by: @hvlad Is it reproducible ? If yes, how long you run the test suite to reproduce it ? Is it possible to limit the whole huge test suite to "relevant" tests only ? |
Commented by: @ibprovider No. Not reproducible. Although, I get the similar "deadlock" errors more or less regulary But it is first time when was fail with such a situation (record not found) 0. thread #2 and #6 inserted test records and commit transactions. 1. thread #6 deletes own records from TBL_CS__OCTETS and get a "deadlock error" ----- I looked into test code ("select" verifications executed in new attachment and with (ofcourse) new transaction) - seem record with ID=1904019 really was lost... I will let you know about any other similar situation. |
Commented by: @hvlad I have few sets of memory and lock table dumps (consistent with each other, i.e. produced at the same time) which
1. Attachment att1 uses page A and wants to lock page B
3. Attachment att1 owns lock for page C (!) and waits for lock for page B i.e. here we have classical deadlock condition.
a) dirty (BDB_dirty flag is set)
page A first, but it can't (as page A is currently used, see point (1) above).
- concurrent handoff's |
Commented by: @hvlad
- detect case when down_grade is called recursively for high precedence page |
Modified by: @dyemanovFix Version: 2.5.3 [ 10461 ] => |
Modified by: @dyemanovFix Version: 2.5.3 [ 10461 ] |
Commented by: @hvlad So far there was no stable test case to validate patch for fb3. Recently, with help of Pavel Zotov, we confirmed it. |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] QA Status: No test => Cannot be tested |
Submitted by: @hvlad
Relate to CORE4372
Votes: 1
The error was found during developing mt-safe page cache in v3.0.
It is reproducible on relatively high load - TPCC with 64 concurrent connections, not disk bound.
It is under investigation currently if Firebird versions prior to v2.5 is affected.
Commits: a07e2ff ef2e6e7 FirebirdSQL/fbt-repository@9131896 FirebirdSQL/fbt-repository@41db3ac
The text was updated successfully, but these errors were encountered: