
If you were logged in you would be able to see more operations.
|
|
|
QA Status: |
Deferred
|
Test Details: |
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.
|
Test Specifics: |
Architecture (SS/CS) specific
|
Sample of code:
create or alter procedure sp_handle_rows (
a_doc_id bigint,
a_old_optype bigint)
as
declare v_gdscode int;
declare v_dd_id bigint;
declare v_this varchar(80) = 'sp_handle_rows';
begin
for
select d.id
from doc_data d
where d.doc_id = :a_doc_id
into v_dd_id
do
begin
delete from qdistr q
where
q.snd_optype_id = :a_old_optype
and q.rcv_optype_id in ( 1200, 3300 )
and q.snd_id = :v_dd_id;
end
when any do
begin
v_gdscode = gdscode;
if ( v_gdscode not in( 335544336, 335544878 ) ) then
begin
in autonomous transaction do
insert into perf_log(
unit,
fb_gdscode)
values(
:v_this,
:v_gdscode);
end
exception;
end
end
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.
|
Description
|
Sample of code:
create or alter procedure sp_handle_rows (
a_doc_id bigint,
a_old_optype bigint)
as
declare v_gdscode int;
declare v_dd_id bigint;
declare v_this varchar(80) = 'sp_handle_rows';
begin
for
select d.id
from doc_data d
where d.doc_id = :a_doc_id
into v_dd_id
do
begin
delete from qdistr q
where
q.snd_optype_id = :a_old_optype
and q.rcv_optype_id in ( 1200, 3300 )
and q.snd_id = :v_dd_id;
end
when any do
begin
v_gdscode = gdscode;
if ( v_gdscode not in( 335544336, 335544878 ) ) then
begin
in autonomous transaction do
insert into perf_log(
unit,
fb_gdscode)
values(
:v_this,
:v_gdscode);
end
exception;
end
end
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. |
Show » |
|