On 9/24/2020 8:10 PM, Viktor Dukhovni wrote:
On Thu, Sep 24, 2020 at 05:34:15PM -0500, deoren wrote:
No, just WAL mode means that we haven't opened all the files that
might later be needed.
If I run all tasks under the postfix user account, how likely am I to
run into issues? Thus far it seems to be working, but I've yet to go a
full 6 hours, much less 24 hours.
Well, you'd be running an unsupported configuration, so how adventurous
do you feel? If the WAL file is ever deleted, it might come back owned
by the wrong user, ... or some other unexpected permission issue.
When Postfix is accessing indexed files directly, they should be
read-only. For concurrent read-write, use a database.
SQLite is an embedded datastore for applications, where typically all
the reads and writes are handled by some component of that application.
For real multi-application concurrency, use a database designed for
that.
Fair enough. Thanks for the explanation, I see where using WAL mode
could end up biting us in this setup. I'll shelve using WAL mode for now
and go back to using the standard DELETE mode.
By using WAL mode I was hoping to avoid this scenario:
"SQL prepare failed: database is locked"
described on the "Postfix with sqlite - Database becomes locked" thread
from this mailing list.
I ran into that a few error a few times with earlier testing before I
enabled WAL mode. I've since implemented transaction support in the app
responsible for regenerating the SQLite db file, so hopefully the
"database is locked" issue will be resolved (hoping for a narrow
contention window).
That said, I saw in that mailing list thread that using this line was
recommended:
PRAGMA busy_timeout = 1000
If a query is defined like this:
### before
query =
SELECT destination FROM local_aliases
WHERE source ='%s'
AND enabled = '1';
would you modify it like so?
### after
query =
PRAGMA busy_timeout = 1000;
SELECT destination FROM local_aliases
WHERE source ='%s'
AND enabled = '1';
