Ron Garret: > >> Isn't SQLite supposed to deal with concurrent access? > >> https://sqlite.org/lockingv3.html > > > > Yes, it does, but the way it ?deals? with it is to throw an error > if one connection tried to read while another is writing. The net
Bleh, it does not retry the operation? What happens when you update the table while some Postfix code is READING from the DB? Does the writer also fail? > result of this is that if Postfix tries to read during a concurrent > update from somewhere else, it fails catastrophically (mail is > actually lost). Losing mail would be a bug in the sending program. Postfix never loses mail because of a fatal error. > It would be nice if postfix would set a non-zero busy timeout. > It?s a simple code change, just a call to sqlite3_busy_timeout. What about https://www.sqlite.org/pragma.html#pragma_busy_timeout ? I don't know if that is a DB property or a session property. > That would not be a guarantee, but it would at least make it > *possible* to safely update a sqliite database in-place. I?m going > to head on over to the postfix-dev list to see if it?s possible > to get this done. If we take this route, then there needs to be a new field in the Postfix sqlite config file that controls the time limit. Wietse
