Nikolaos Milas:
> On 23/1/2013 3:43 ??, Nikolaos Milas wrote:
>
> > Interestingly, at first I tried it but it didn't seem to produce any
> > output at all (I had to break with Ctrl-C):
> >
> > # postmap -s /var/lib/postfix/verify_cache
> > ^C
> > # postmap -s btree:/var/lib/postfix/verify_cache
> > ^C
> > # postmap -q u...@example.com /var/lib/postfix/verify_cache
> > ^C
> > # postmap -q u...@example.com btree:/var/lib/postfix/verify_cache
> > ^C
I have mentioned before that the verify(8) daemon locks the Berkeley
DB file exclusively. Concurrent read/write access is not safe with
these files. The exclusive lock guarantees that verify(8) will not
crash or do silly things when some other Postfix program changes
the database. The lock also ensures that other Postfix programs
will not crash or do silly things when verify(8) changes the database.
You could do this:
# cp /var/lib/postfix/verify_cache.db tempfile.db
# postmap -s btree:tempfile.db
Cross your fingers, and if it breaks, repeat the two commands.
The new LMDB database type is safe for concurrent read/write access;
however this currently has an open problem when creating a very
large database file from scratch (as with the "postmap" command).
That is not an issue with verify(8) which makes only incremental
updates.
Of course there is no guarantee of what you will get when you dump
a large database while it is being modified, even when the database
file is safe for concurrent read/write access. But at least the
programs will not crash or do silly things.
Wietse
