Are there any known bugs with database compaction and TDS? On 4.4.16,
free space is sometimes not returned to the file system, and the
operation hangs on a certain table. Starting another operation at
that point (for example, a checkpoint) leads to a "run recovery" error
message. After I did that, I tried with 4.4.20, but then, running
compaction alone (while not touching the database at all) triggers the
"fatal region error detected; run recovery" error.

Florian,

Sometimes compact cannot return space to the file system in a single
call if there are not many pages on the free list when it begins. This
is because in order to free pages to the file system they must be at
the end of the file and if those pages are logically at the begining of
the database it will not have any pages to swap them with. This could
be the effect you are seeing. Also if you have multiple databases in a
file, the higher numbered pages may be in a different database than the
one you compact.

As far as bugs that cause hangs and panics. I would need more details
to analyze what is happening. When a "run recovery" error is first
generated it is always preceeded by a more descriptive message. Be
sure that your application is specifying verbose messages:
http://www.sleepycat.com/docs/api_cx...t_errcall.html
http://www.sleepycat.com/docs/api_cx...t_errfile.html
http://www.sleepycat.com/docs/api_cx...or_stream.html
(after that point other commands will just get the "run recovery"
error).

Where you able to determin where the hang was occuring in the code? A
stack trace would be useful here.

Michael Ubell
Sleepycat Software.

* Mike:

Ah, thanks for the explanation.

Unfortunately, my error handling framework only stores the last
such message, but with a suitable printf call, I get:

notice: compacting ipv4
** Berkeley DB error: Not enough room in parent: ipv4.db: page 76384
** Berkeley DB error: PANIC: Invalid argument
** Berkeley DB error: PANIC: fatal region error detected; run recovery

(This is on amd64, with Berkeley DB 4.4.20.)

This happens with the 4.4.16 version on i386. Unfortunately, it's
difficult for me to switch to 4.4.20 because the vendor changed the
region format during the 4.4.16 -> 4.4.20 switch.

Florian,

There is a patch that fixes a bug that has this symptom. It is
possible that your situation could be fixed by the patch if you use
sorted duplicates (DB_DUPSORT) in your database. You should send a
request to support (AT) sleepycat (DOT) com if you want to try the patch.

You should be able to upgrade your environment to 4.4.20 by removing
the environment using 4.4.16 using the DB_ENV->remove interface and
then recreating it under 4.4.20. This will not remove your database or
log files, just the shared region backing files.

Michael Ubell
Sleepycat Software.