Simon Riggs wrote:
> We can generalise this as three closed questions, answered either Yes
> (Synchronous) or No (Asynchronous)
> 
> * Does WAL get forced to disk on primary at commit time?
> * Does WAL get forced across link to standby at commit time?
> * Does WAL get forced to disk on standby at commit time?
> 
> In code, these are simple if tests: Do we wait, or not?
> 
> We could represent this with 3 parameters:
> synchronous_commit = on | off
> synchronous_standby_transfer = on | off
> synchronous_standby_wal_fsync = on | off
> 
...
> Or we could use just two parameters:
> synchronous_commit = on | off
> synchronous_replication = 'AA', 'SA' or 'SS'
>   with A = Asynchronous, S = Synchronous 
>   which corresponds with DRBD's algorithms like this
>       DRBD A = AA
>       DRBD B = SA
>       DRBD C = SS
> 
> Or we could use just a single parameter
> synchronous_commit = 'AAA', 'SAA', 'SSA', 'SSS' or on |off when no
> log-based replication is defined

First, I love this kind of control.

Second, I think our current control for the main/master are sufficient
that we don't need to add additional variables for this, so we can focus
just on whether we wait for the slave.

Third, we can control whether the slave WAL fsync's by setting things on
the slave, so I don't think we need a master setting for that.

Fourth, I don't think the boolean idea will work because there are
boolean combinations that are illogical, like having
synchronous_standby_transfer off and synchronous_standby_wal_fsync on.

I think you need to make it an enumerated type like log_min_messages; 
something like:

        wal_transfer_wait

with values of:

        nothing:        have network traffic send WAL as needed
        netflush:       wait for flush of WAL network packets to slave
        process:        wait for slave to process WAL traffic and
                        optionally fsync

The 'process' option either waits for fsync on the slave or not
depending on how the slave is configured, meaning you could use
synchronous_commit off to not wait for the fsync to disk.

I think we can add a table in the documention to show how to set things
up in postgresql.conf for async master and async slave, and other
combinations.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to