On 04/01/2014 09:39 AM, Simon Hobson wrote:
Nigel Kukard <[email protected]> wrote:
Originally I was running a single PolicyD and MySQL server on the backend.
Apart from some performance problems (which were the subject of a thread on
here at the time), PolicyD never gave any problems. It was the Postfix access
to the DB that gave problems - a lot of lookups for Postfix Admin.
Do you have query cache enabled? On some installations we'd had to give it
quite a substantial amount of RAM to get optimum results.
I couldn't say what the settings were at the time - things have changed since.
I probably do need to go back and check the tuning again.
Another thought does come to mind for the OP's problem. What happens if PolicyD
fails to retrieve a quota tracking record ? I'm guessing it creates a new one -
if one exists when a new one is added, does the old one get removed first, or
updated to the new values, or ... ?
It tries an update first, if that fails an insert, if that fails (extremely
rare due to DB clash) the mail is deferred as a DB error (failed insert)
occurred.
I was thinking more of :
- read fails, so daemon doesn't know there is an existing record (should it
know there was a failure ?)
- daemon creates new record (it doesn't try an update as it "knows" there isn't
an existing record)
- new record has count set to 1
So it's really a case of what happens when it adds a new record and one already
exists. Depending on how it's coded, I could see it doing any of insert fails,
database gets duplicate record, insert overwrites old record, something else ?
I believe the colums are indexed , so it wouldn't be possible to create
a duplicate
-N
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
