On 11 November 2015 at 05:37, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
