Peter Geoghegan <peter.geoghegan86 at gmail.com> writes:
> What sort of risk am I assuming specifically to replication by turning
> off synchronous_commit on the slaves but not on the master?

The risk is that a subscriber would report back that it has committed
changes, when those changes get swept back by a failure (e.g. - power
outage that loses a little bit of work).

I see the edge case, and it's regrettably unpleasant.

Consider...


  - Node #2 claims to have committed up to transaction T5, but 
    the WAL only really has records up to T3.

  - Node #1, the "master", got the report back that #2 is up to date to
    T5.

  - Node #2 experiences a failure (e.g. - power outage).

There are two possible outcomes, now, one OK, and one not so OK...

  1.  OK

      Node #2 gets restarted, replays WAL, knows it's only got data up
      to T3, and heads back to node #1, asking for transaction T4 and
      others.

      No problem.


  2.  Not so OK :-(

      Before node #2 gets back up, node #1 has run an iteration of the
      cleanup thread, which trims out all the data up to T5, because the
      other nodes confirmed up to that point.

      Node #2 gets restarted, replays WAL, knows it's only got data up
      to T3, and heads back to node #1, asking for transaction T4 and
      T5.

      Oops.  Node #1 just trimmed those out.

The race condition here is easy to exercise - you just need to suppress
the restart of node #2 for a while, long enough for node #1 to run the
cleanup thread.

You may evade the problem somewhat by setting the parameter
"cleanup_interval" to a larger value.  (I'm assuming version 2.0, here.)

Unfortunately, any time the outage of node #2 could exceed that
interval, the risk of losing log data inexorably emerges.
-- 
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];;
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"