> 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

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.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to