Dimitri Fontaine wrote:
> IMO the real fun begins when we talk about multi-slaves support and
> their roles (a failover slave wants the master to wait for it to have
> applied the WAL before to commit, a reporting slave not so much). So
> you'd set the Availability level on each slave and wouldn't commit on
> the master until each slave got what it's configured for, or something
> like that.
>
Ultimately the commit is stuck waiting for the slowest committing sync
operation on the list; it's the bottleneck. Let's presume that the
commit waits can be done in parallel, after sending the transaction to
every slave. Given that and the situation you describe, having per-node
sync levels only turns out to be a useful optimization if the reporting
slave commits slower than the failover slave does. The master is going
to be stuck waiting for the slowest one of the batch regardless of
whether you've optimized them individually.
There is a related situation that I think a per-node sync option would
be more obviously useful for: local failover slave, remote disaster
recovery slave over a WAN, where you accept that a serious disaster
taking out a whole data center will lose some transactions. In that
situation, you'd probably want fsync for the local slave, while going
async for the remote datacenter.
If the commits are done in a serial fashion, tuning sync per-node would
be much more valuable in many use cases.
Regardless, I wouldn't want to burden the first sync rep version with
this requirement. Let's wait until the current scope is cleared before
trying to move the goalposts for the people working on that.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
