db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Resolved: (DERBY-1189) latch self deadlock when running inplace compress
Date Fri, 07 Apr 2006 16:28:26 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1189?page=all ]
     
Mike Matrigali resolved DERBY-1189:
-----------------------------------

    Resolution: Fixed

Checked in the fix:
Author: mikem
Date: Thu Apr  6 23:11:13 2006
New Revision: 392194

URL: http://svn.apache.org/viewcvs?rev=392194&view=rev
Log:
DERBY-1189

inplace compress could self deadlock on a latch/latch conflict.  Changed
the insert page find code for defragment to never return a page which is
higher than the source page of the row.  Previously the upper level code
made this decision, but that was too late.  As part of the change also 
optimized the "unfilled" search to be biased towards those pages near
the front of the container.  Checkin includes simple sql script which 
reproduced the deadlock prior to the fix.



Added:

> latch self deadlock when running inplace compress
> -------------------------------------------------
>
>          Key: DERBY-1189
>          URL: http://issues.apache.org/jira/browse/DERBY-1189
>      Project: Derby
>         Type: Bug

>   Components: Store
>     Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.2.0.0
>     Reporter: Mike Matrigali
>     Assignee: Mike Matrigali
>      Fix For: 10.2.0.0

>
> The following script , before the fix, causes online compress to attempt to latch the
same page twice in a nested user transaction causing a self deadlock of the form:
> ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks and
> waiters is:
> Lock : LATCH, T1, Page(35,Container(0, 1728))
>   Waiting XID : {385920, BaseContainerHandle:(Container(0, 1728))} , APP, CALL S
> YSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1)
>   Granted XID : {385920, BaseContainerHandle:(Container(0, 1728))}
> . The selected victim is XID : 385920.
> script that reproduces it:
> drop table t1;
> create table t1 (i integer primary key, j integer, c char(200));
> insert into t1 values (1, 1, 'a');
> insert into t1 (select t1.i + 2,    t1.j + 2,    t1.c from t1);
> insert into t1 (select t1.i + 4,    t1.j + 4,    t1.c from t1);
> insert into t1 (select t1.i + 8,    t1.j + 8,    t1.c from t1);
> insert into t1 (select t1.i + 16,   t1.j + 16,   t1.c from t1);
> insert into t1 (select t1.i + 32,   t1.j + 32,   t1.c from t1);
> insert into t1 (select t1.i + 64,   t1.j + 64,   t1.c from t1);
> insert into t1 (select t1.i + 128,  t1.j + 128,  t1.c from t1);
> insert into t1 (select t1.i + 256,  t1.j + 256,  t1.c from t1);
> insert into t1 (select t1.i + 512,  t1.j + 512,  t1.c from t1);
> insert into t1 (select t1.i + 1024, t1.j + 1024, t1.c from t1);
> delete from t1 where j=1;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> delete from t1 where j=2;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> delete from t1 where i > 1024;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> delete from t1 where i < 512;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message