[Xapian-discuss] problem on closing writable databases

[Olly Betts]

On Tue, Feb 03, 2009 at 05:56:15PM +0100, Markus Wörle wrote:
> because of the issue, that xapian btrees thin out in the longrun

I'm not sure I follow.  Do you just mean that if you delete a lot of
documents, you don't immediately get the space back?  That's certainly
true, but if you index more documents, that space should get reused.
If the Btrees really end up becoming less efficiently used over time,
I suspect that means there's a bug somewhere.

> I read earlier that "cat" is used for locking, and I saw that its  
> opening the flintlock files. But why does it hold these .DB file open?  

Thanks for asking this question - I think there is a bug here.

If I open WritableDatabase A then open WritableDatabase B, and then
close and delete WritableDatabase A, then the locking process for B will
still have open filehandles for the .DB files in A and so that disk
space won't be released right away.

After we fork() the locking process but before we exec() /bin/cat we
should close all the fds apart from that for the pipe to our parent.

I'll fix that, and backport the fix for 1.0.11.

> Is there a way to get these files closed properly without acutally  
> quitting and restarting the process (which probably would by my  
> workaround)?

In C++, you'd just make sure that you close the old db before opening
the new one to workaround this bug.  But in Perl the only way to close
the old db is $db=undef; which you are already using.  I guess the
C++ object destructor may not get called right away.

SVN trunk adds a Database::close() method, but that's probably not a
great help to you currently.

Cheers,
    Olly