On 12-10-11 12:57 AM, Adam Thompson wrote:
to /etc/postfix/client_access (and remembering to run postmap on it) eventually convinces Postfix to let this message in. (But typically not immediately, which I still don't understand. Ideas?) Only one of those lines should be necessary, but I've never figured out which one :-).
The following reference provides an explanation: http://www.postfix.org/DATABASE_README.html
Process dependent ... I generally reload and/or restart, depending on what is being changed. :-)
Dan.
------------------------------------------------------------------- snippet below ------------------------------------ Maintaining Postfix lookup table files
When you make changes to a database while the mail system is running, it would be desirable if Postfix avoids reading information while that information is being changed. It would also be nice if you can change a database without having to execute "postfix reload", in order to force Postfix to use the new information. Each time you do "postfix reload" Postfix loses a lot of performance.
If you change a network database such as LDAP, NIS or SQL, there is no need to execute "postfix reload". The LDAP, NIS or SQL server takes care of read/write access conflicts and gives the new data to Postfix once that data is available.
If you change a regexp: or pcre: file then Postfix may or may not pick up the file changes immediately. This is because a Postfix process reads the entire file into memory once and never examines the file again.
If the file is used by a short-running process such as smtpd(8), cleanup(8) or local(8), there is no need to execute "postfix reload" after making a change.
If the file is being used by a long-running process such as trivial-rewrite(8) on a busy server it may be necessary to execute "postfix reload".
If you change a local file based database such as DBM or Berkeley DB, there is no need to execute "postfix reload". Postfix uses file locking to avoid read/write access conflicts, and whenever a Postfix daemon process notices that a file has changed it will terminate before handling the next client request, so that a new process can initialize with the new database.