Wietse Venema: > Thanks for the patch. > > Stefan Jakobs: > > I'am not aware of any dead-lock issues. The sequence pseudo-thread > > will query the database only once with the first key. For every > > next key the sequence pseudo-thread is working with the results > > in the memory. With a very large database the size of the response > > may be a problem. But a INSERT/DELETE/UPDATE operation will not > > conflict with the sequence pseudo-thread. Finally, I can not > > prove if the code is dead-lock safe. > > It appears that this sequence() implementation uses memory in > proportion to the database size. That is not acceptable. Would it > be possible to maintain state with a limited amount of memory for > a database cursor? > > By design, Postfix memory usage must not keep growing with increasing > data size, queue size, message size, database size etc. This is > necessary to ensure sane handling of overload. It is not acceptable > that Postfix becomes deadlocked under overload.
Looking over MySQL documentation, there appears to be a HANDLER primitive that appears to support FIRST/NEXT sequential access without using an amount of memory that grows with database size. http://dev.mysql.com/doc/refman/5.5/en/handler.html http://dev.mysql.com/doc/refman/4.1/en/handler.html This approach seems to have similar consistency limitations as other Postfix maps that support FIRST/NEXT sequential access while database updates are happening, and that is not a problem. When we use FIRST/NEXT for database cleanup, it is sufficient if we clean up most of the stale entries. Wietse
