Re: Transaction Snapshots and Hot Standby - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Transaction Snapshots and Hot Standby
Date
Msg-id 1221211225.7026.2.camel@huvostro
Whole thread Raw
In response to Re: Transaction Snapshots and Hot Standby  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Transaction Snapshots and Hot Standby  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
On Fri, 2008-09-12 at 09:45 +0100, Simon Riggs wrote:
> On Thu, 2008-09-11 at 15:42 +0300, Heikki Linnakangas wrote:
> > Gregory Stark wrote:
> > > b) vacuum on the server which cleans up a tuple the slave has in scope has to
> > >    block WAL reply on the slave (which I suppose defeats the purpose of having
> > >    a live standby for users concerned more with fail-over latency).
> > 
> > One problem with this, BTW, is that if there's a continuous stream of 
> > medium-length transaction in the slave, each new snapshot taken will 
> > prevent progress in the WAL replay, so the WAL replay will advance in 
> > "baby steps", and can fall behind indefinitely. As soon as there's a 
> > moment that there's no active snapshot, it can catch up, but if the 
> > slave is seriously busy, that might never happen.
> 
> It should be possible to do mixed mode.
> 
> Stall WAL apply for up to X seconds, then cancel queries. Some people
> may want X=0 or low, others might find X = very high acceptable (Merlin
> et al).

Or even milder version.

* Stall WAL apply for up to X seconds, 
* then stall new queries, let old ones run to completion (with optional
fallback to canceling after Y sec), 
* apply WAL. 
* Repeat.

-------------
Hannu




pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Transaction Snapshots and Hot Standby
Next
From: Heikki Linnakangas
Date:
Subject: Re: New FSM patch