[#CORE-2848] "lock conversion denied" or "lock denied" error - Firebird RDBMS Issue Tracker http://tracker.firebirdsql.org/browse/CORE-2848
http://tracker.firebirdsql.org/browse/CORE-2848 [#CORE-2848] "lock conversion denied" or "... http://tracker.firebirdsql.org/browse/CORE-2848 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. View on tracker.firebirdsql.org http://tracker.firebirdsql.org/browse/CORE-2848 Preview by Yahoo Same or similar bug still exists in 2.5.3 release and frequently (1-10 times per day) appears in our production environment, even after backup/restore with 2.5.3 Conditions to reproduce: *) win2008 x64 (in production also appears on 2003 32bit windows, but much less frequently) *) 32-bit classic server *) 1 writer thread, quasi-randomly updating short (~1000 records) table, causing heavy record fragmentation, commit one time per 15 seconds. To repeat production db access patterns I have tried to force fragmentation by switching between random and non-random data generation for fields. Also, bug probability appears to depend on record size. *) 10-20 reader threads, reading same table, different isolation levels and read/write modes, commit one time per 15 seconds. Not sure if this really needed. *) every 10 minutes there is a scheduled task to perform sweep on database. In production this service task scheduled one time per day. *) every minute all connections are closed and opened again. Approximately 1-5 time per day writer thread connection returns an error: deadlock.deadlock. page 34512, page type 5 lock denied. with corresponding message in firebird.log: WIN200864 Wed Nov 12 21:21:27 2014 Database: gcstress page 34512, page type 5 lock denied (216) or other similar messages WIN200864 Wed Nov 12 08:25:36 2014 Database: gcstress page 256, page type 4 lock conversion denied (215) (page 256 is primary pointer page for heavily updated table) I have been able to reproduce it on test database and have database file, lock print and failing fb_inet_server process debug dump (all when fb_inet_server stopped on debugger breakpoint on corresponding fb_msg_format calls in cch.cpp/lock_buffer) Should I go to issue tracker and post duplicate of this message there? Also whom I should send debug dumps (400 mb archive link)
