From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Richard Huxton <dev(at)archonet(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transaction Snapshots and Hot Standby |
Date: | 2008-09-12 09:20:25 |
Message-ID: | 1221211225.7026.2.camel@huvostro |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2008-09-12 09:21:06 | Re: Transaction Snapshots and Hot Standby |
Previous Message | Zdenek Kotala | 2008-09-12 09:14:58 | Re: hash index improving v3 |