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

Reply via email to