> This should be due to internal deadlocks in the berkeley db code. (This can > happen when two different processes are trying to upgrade read locks to > write locks or split a page.) Generally the bigger the database is the less > likely this is to happen, which is why you might see it only on your less > loaded server. > > It's one of those "if it isn't happening constantly, it isn't a problem" > deals.
Given that it's for the deliver.db, which is used for duplicate delivery suppression and sieve, will an aborted locker result in sieve not correctly processing an email? Rob
