On 11 November 2015 at 05:37, Thomas Munro <thomas.mu...@enterprisedb.com>
Many sites use hot standby servers to spread read-heavy workloads over more
> hardware, or at least would like to. This works well today if your
> application can tolerate some time lag on standbys. The problem is that
> there is no guarantee of when a particular commit will become visible for
> clients connected to standbys. The existing synchronous commit feature is
> no help here because it guarantees only that the WAL has been flushed on
> another server before commit returns. It says nothing about whether it has
> been applied or whether it has been applied on the standby that you happen
> to be talking to.
Thanks for working on this issue.
> 3. Commit on the primary with "causal_reads = on" waits for all
> 'available' standbys either to apply the commit record, or to cease to be
> 'available' and begin raising the error if they are still alive (because
> their authorizations have expired).
This causes every writer to wait.
What we want is to isolate the wait only to people performing a write-read
sequence, so I think it should be readers that wait. Let's have that debate
up front before we start reviewing the patch.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services