> There are 2 GUCs that would control the behaviour here: > > transaction_guarantee = on | off
> has been enabled. Use this parameter with care; if you find > yourself wanting to use this parameter all of the time you > should consult a psychiatrist or change open source databases. If you guarantee your customers, that you wont loose a transaction that has already been committed you need to at least have synchronous replication to a remote site. Since not many installations have that, I do find it funny that people imply so much safety only by syncing the wal. Without sync replication a "buffered wal" as proposed only increases the chances that you loose something. It certainly is no change from safe heaven to abyssmal hell. So I think the part after the semicolon can safely be dropped. Many will be able to use it always, without changing to another db :-) > commit_fsync_delay = 0...10000 microseconds (0 = off, default) > Controls how often the WALWriter issues an XLogFlush() > SIGHUP, so set once for each server, in postgresql.conf > This provides a maximum time window of potential data loss > in the event of a server crash for transactions that choose > transaction_guarantee = off. This parameter has no effect > on transactions that choose transaction_guarantee = on. The wal sync method probably needs to be considered ? If the wal is opened with open_datasync, how does that affect the performance, or do you ommit the write and leave that to the WALWriter also ? You probably also want more wal_buffers in such a setup. It may be better to trigger the WALWriter with wal_buffer fill-level instead of an extra parameter ? It is imho great that you are working on this. I always thought it impossible, because WAL (write ahead) implied to me, that you are not allowed to do some data/index page changes before wal is on disk. Andreas ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
