Re: half-atomically rebuild databases

[Kristaps Dzonsons <kristaps@bsd.lv>]

On 01/03/12 14:19, Joerg Sonnenberger wrote:
> On Tue, Jan 03, 2012 at 02:07:48PM +0100, Kristaps Dzonsons wrote:
>> On 01/03/12 13:45, Joerg Sonnenberger wrote:
>>> On Sun, Jan 01, 2012 at 05:29:58PM +0100, Ingo Schwarze wrote:
>>>> Hi Joerg,
>>>>
>>>> Joerg Sonnenberger wrote on Sun, Jan 01, 2012 at 04:55:08PM +0100:
>>>>> On Sun, Jan 01, 2012 at 04:45:38PM +0100, Ingo Schwarze wrote:
>>>>
>>>>>> This is not perfect because the mandocdb process might get -KILLed
>>>>>> between the two renames, but i don't see a syscall anywhere to
>>>>>> atomically rename *two* files.
>>>>
>>>>> Why do you have to?
>>>>
>>>> There are two files to rename(2):  whatis.{db,index}.
>>>
>>> Well, let me repeat the question, that is the point of having two
>>> databases.
>>
>> Joerg---you mean to ask why I originally used two separate database files?
>
> Yes.

Joerg,

Duplication.  By having the keyword database point to the index database 
entries, I avoided having duplicate index data everywhere---and this 
data can be huge since it includes titles, descriptions, and so on. 
Considering that the number of keywords is expected to grow as we add 
more values (full-text search?), this is quite important.  Since libdb 
has only one table per file...

It's still debatable whether using recno(3) for the index is a good 
idea.  The general usage is to hit the btree(3) then look up in the 
recno(3) (btree(3) is harmless, I think, but useless: we don't do 
lexicographic lookup as I'd originally thought).

However, look-up is slow in recno(3).  I can definately see a case for 
using btree(3) or even hash(3) in place of recno(3).

Make sense?

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv