From: Jim Starkey
Date: January 21 2009 5:22pm
Subject: Re: When you have a chance...
List-Archive: http://lists.mysql.com/falcon/413
Message-Id: <497759BE.4050707@nimbusdb.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Vladislav Vaintroub wrote:
>   
>> -----Original Message-----
>> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped]
>> Sent: Wednesday, January 21, 2009 5:42 PM
>> To: Jim Starkey
>> Cc: Christopher Powers; Ann W. Harrison; FalconDev
>> Subject: Re: When you have a chance...
>>
>>  > Jim Starkey wrote:
>>     
>>> Kevin, let's rethink this.  In the original design, this wasn't an
>>>       
>> issue
>>     
>>> because the only transaction that would look at the data was in the
>>>       
>> same
>>     
>>> thread as the chill, so no race condition could occur.  Did I miss
>>> something, or did something change that made this assumption
>>>       
>> unwarranted?
>>
>> Jim,
>>
>> I think that Table::checkUniqueRecordVersion() and
>> Index::duplicateKey()
>> called from Index::garbageCollect() have always needed to traverse the
>> whole record chain looking at the data buffer if it exists.  These
>> functions are separate threads than the one doing the chilling.
>>
>> The former must look to see if there is a duplicate conflict with ANY
>> record old, active, or pending.
>>     
>
> Interesting, I still do not get it, why we checking for uniqueness during
> garbage collection? We have no possibility to report an error to user at
> this stage.
>
>
>
>   
We need to determine whether an index node for a departing record needs 
to be deleted.  If the value is represented in a record version that is 
hanging around, we don't need to remove the node from the index.  
Otherwise, we do.

The same problem (and solution) applied to blob garbage collection.

-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376