On 2/23/21 2:18 PM, Wietse Venema wrote: > Ron Garret: >>> If we take this route, then there needs to be a new field in the >>> Postfix sqlite config file that controls the time limit. >> Not necessarily. You could just hard-code a reasonable value (like >> 1 second), or make it a #define so you need a recompile to change >> it. That?s sub-optimal, obviously, but still a major improvement >> over the current situation for very little effort and no down-side >> that I can see. > The limit should be configurable. It takes: > > - one line of code to define a C variable, > > - one line of code to read its value from an sqlite_table configuration > file (or to use a documented default value), > > - a few lines of text to document the new field in the sqlite_table manpage. > > Wietse
One thng to look at is WAL mode. WAL mode increases the cost of writes to the database, as all writes become two stage, first to the WAL journal, and then flushed to the main database (called A checkpoint), and reads reads can get a bit more expensive if the second stage of the write gets delayed by long accesses (but that may not be an issue with postfix). In exchange, the database allows for simultaneous reads and writes, except possibly for the period when the second phase of the writes are occurring, and it will try to allow as much overlap there as possible, and try to find a time when no readers are active to do this operation. Without a busy timeout being set, the reader should only get a busy in fairly rare conditions, the main one being if the last connection to the database is closing, then SQLite does some cleanup that locks the database for just a little bit, or if the last connection 'crashes' than the next connection will do some cleanup. Even a fairly short busy wait should handle these cases most of the time. -- Richard Damon
