Vacation

[Ian G Batten]

On 19 Nov 07, at 2139, Scott Adkins wrote:

> This does bring up an important point... we had to disable duplicate
> suppression on our server because it was just causing too much  
> contention.
> When every single mail message being delivered has to check against  
> the
> database, it is a problem.

The checking's not the problem, as the 99.9% case is an update.  In  
other words, if the rate of duplicates were high, you could lock it  
for reading, check the message was unique, and then if that gave a  
positive response lock it for update and perform the update.  Yes,  
there's a race condition, but it's small and benign.

However, in the real world this gains you nothing, because the rate  
of duplicates is vanishingly small.  You buy complexity and a race  
condition for degraded performance (the lock upgrade is expensive).

There are other possible solutions.  One would be a per-user, or per- 
user-initial-letter, duplicate database.  Another would be to not  
bother syncing the database (I think this is what berkeley-nosync  
does, but that doesn't help skiplist users).

ian