Hi Richard,

I found out I did not solve the problem yesterday because the btree commit
got stuck again.  After some debugging, I saw the dirty list in the pager
became circular and caused infinite loop... (maybe due to my misuse?)  So I
put in an extra check into the function makeDirty(PgHder *pPg) in pager.c to
make sure the incoming pPg is not already in the list... something like:

static void makeDirty(PgHder *pPg)
{
    PgHdr *pChk;  // checker pointer
    ...
    pPg->dirty = 1;  // after this line of original code 
    pChk = pPager->pDirty;
    while (pChk)
    {
       if (pChk == pPg) return;  // jump out if same entry is on the list
       pChk = pChk->pDirty;
    }
    ...  // original code continues.
}   

It seems to work now.  I am not sure what's the "right" way to fix this
since I am new to the code.  

Regards,
William

-----Original Message-----
From: William Chan [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 09, 2006 7:25 PM
To: 'sqlite-users@sqlite.org'
Subject: RE: [sqlite] Second Btree Transaction stuck at commit

Thanks Richard.  I need btree indexing in a commercial project and looks
like everybody is charging fee... and it wouldn't be a problem if I am the
guy who is writing the check...  I just did some simple stress test
(inserting and query a million records) and you guys save my behind.  

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 09, 2006 7:09 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Second Btree Transaction stuck at commit

"William Chan" <[EMAIL PROTECTED]> wrote:
> Hi Guys,
> 
> I think I figure out my problem.  Looks like I need to close the cursor
and
> create a new cursor between the two Btree transactions.  Then the second
> btree commit will go thru.  Can someone explain to me why?  Thanks.
> 

Before you go too far with this Btree project, you do understand
the terms of use, right?

   *  The BTree interface is an internal interface and is
      not documented or supported.

   *  The BTree interface is only tested in ways that are
      used by the SQL layer and will likely break if you use 
      it differently.

   *  The BTree interface is not intended for external use
      and therefore likely to have many undocumented
      quirks and idiosynchrasies.

   *  The BTree interface has changed without notice in the
      past and will likely change again without notice in 
      the future.

--
D. Richard Hipp   <[EMAIL PROTECTED]>



Reply via email to