Found nn messages in the processing-messages database

[Glenn Steen]

2009/4/20 Kai Schaetzl <maillists at conactive.com>:
> Glenn Steen wrote on Mon, 20 Apr 2009 12:44:14 +0200:
>
>> Well, then you haven't got a particularly large/lengthy SQL log (like
>> for MailWatch), have you?
>
> I regularly purge. The log I'm looking at has about 60.000 messages. How many
> do you need on a day for getting duplicates?
>
Well, as said ... it depends a bit on how you layout your filesystems
too... The key here is inode reuse... and vou need have a bit of
volume, so that the reuse issue becomes an issue, since the the queue
ID will depend on the microsecond and the inode number:-). But there
truly is an issue that need this solution, however small it might seem
to you.

> If you had, you'd see the problem. Also
>> depends on fs, of course.
>
> Is there some some documentation at postfix.org on this?
>
The code? This isn't an issue for normal PF use, since the queue ID
only need be unique as long as the queue file actually exists... But
is you do SQL logging (as we tend to do:-), it becomes an issue...
This is also why no effort will ever be forthcoming from the PF
devs... It's simply not their problem.

>>
>> > And I don't see how changing the algorithm for the five-letter-word would
>> > solve the problem with the processing database.
>> >
>> If you go from totally random to deterministic/file, you'd still get
>> the needed uniqueness as well as the same key for the same queue file
>> (in the processing DB)... Which seems to be the problem needing to be
>> solved...?
>
> Oh, if you use the file itself, yes ... I was thinking of something, uhm,
> well, I don't know.
>
:-)

> Anyway, the point is, that many of us will simply don't need this. It's just
> some more milliseconds added to processing. In the recent past people have
> already complained several times about performance. Why hamper performance
> where it is not necessary?
>
I think Jules is aiming at microseconds...:-). And as such, well spent;)
Who knows, perhaps one should do it as an option ... Like: if you use
the processing DB, then you get deterministic "entropy" added to the
queue file name, else you get the regular entropy as we have had for
quite some time now.

> Btw, Julian, you wanted me to remind you that the processing db option should
> be set to off by default! :-)
>
> Kai
>

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se