| Subject | lock conversion denied/lock denied bug still exists in FB 2.5.3 |
|---|---|
| Author | |
| Post date | 2014-11-12T18:55:17Z |
[#CORE-2848] "lock conversion denied" or "lock denied" error - Firebird RDBMS Issue Tracker
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.
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)