| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Bruce Momjian <bruce(at)momjian(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Hot Standby query cancellation and Streaming Replication integration |
| Date: | 2010-02-27 05:08:35 |
| Message-ID: | 4B88A8D3.2070406@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Aidan Van Dyk wrote:
> Would we (ya, the royal we) be willing to say that if you want the
> benifit of removing the MVCC overhead of long-running queries you need
> to run PITR backup/archive recovery, and if you want SR, you get a
> closed-loop master-follows-save-xmin behaviour?
>
To turn that question around a little, I think it's reasonable to say
that closed-loop master-follows-slave-xmin behavior is only practical to
consider implementing with SR--and even there, it should be optional
rather than required until there's more field experience on the whole
thing. Whether it's the default or not could take a bit of debate to
sort out too.
If you think of it in those terms, the idea that "you need to run PITR
backup/archive recovery" to not get that behavior isn't an important
distinction anymore. If you run SR with the option enabled you could
get it, any other setup and you won't.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-02-27 05:10:50 | Re: Lock Wait Statistics (next commitfest) |
| Previous Message | Aidan Van Dyk | 2010-02-27 04:53:48 | Re: Hot Standby query cancellation and Streaming Replication integration |