Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct

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