If you were logged in you would be able to see more operations.
Letters to / from Vlad: 29-sep-2014. As he said, this bug could be reproduced in the single attachment, w/o concurrent attachments. Hope that such test will be implemented.
Architecture (SS/CS) specific
Sample of code:
create or alter procedure sp_handle_rows (
declare v_gdscode int;
declare v_dd_id bigint;
declare v_this varchar(80) = 'sp_handle_rows';
from doc_data d
where d.doc_id = :a_doc_id
delete from qdistr q
q.snd_optype_id = :a_old_optype
and q.rcv_optype_id in ( 1200, 3300 )
and q.snd_id = :v_dd_id;
when any do
v_gdscode = gdscode;
if ( v_gdscode not in( 335544336, 335544878 ) ) then
in autonomous transaction do
insert into perf_log(
Here it might be that in WHEN ANY section value of `gdscode` variable can be 0 (ZERO) rather than one that reflects lock-conflict.
This occurs only in SuperCLASSIC (and only in 3.x) and never in SuperServer.
Two or more concurrent attaches must work at the same data of table QDistr. After some time record in log table ('PERF_LOG') will appear with fb_gdscode = 0.
I've sent full test to Vlad, got from him instruction where to update source and hope that this will work OK (currently testing it; final report will be later).
PS. Many thanks to Vlad. This was headache during last two monthes.