TechnoSophos wrote:

Using an HDB backend, if I set the dbnosync parameter in slapd.conf, how often will modifications be flushed to the underlying database?

The DB_TXN_NOSYNC flag affects the transaction log file, not the database files. Using NoSync means the log file will never be explicitly flushed, so it will only get written out whenever the log buffer overflows.

Modifications to the databases are cached separately and will only get written from the BDB cache to the database files when dirty pages are forced from the cache, or during a checkpoint.

I did not find the Berkeley DB documentation to be terribly helpful in this case. It mentions that more frequent checkpointing can help: (http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_...)

Should I be using the checkpoint parameter in slapd.conf?

Yes.

I was under the impression (based on threads I have seen in other mailing lists) that checkpoint didn't actually do anything anymore.

I don't know what other lists you're referring to, but they're wrong.

(And I have not had much luck with using txn_checkpoint in the DB_CONFIG file -- it produces errors).

txn_checkpoint is not documented as a valid DB_CONFIG keyword anywhere in the BerkeleyDB documentation, so that's not surprising.

I'm not asking for troubleshooting help on fixing checkpointing. I just want to know how risky it is to use dbnosync, and if checkpointing can help minimize risks.

Yes, checkpointing will minimize the risk. How risky is NoSync - depends entirely on your hardware and software environment.