| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> | 
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> | 
| Cc: | 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 08:45:46 | 
| Message-ID: | 1221209146.3913.948.camel@ebony.2ndQuadrant | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
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).
-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2008-09-12 09:02:32 | Re: pg_regress inputdir | 
| Previous Message | Peter Eisentraut | 2008-09-12 08:44:51 | Re: What is d2mdir? |