| From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| 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 04:53:48 |
| Message-ID: | 20100227045348.GK7843@oak.highrise.ca |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Greg Smith <greg(at)2ndquadrant(dot)com> [100226 23:39]:
> Just not having the actual query running on the master is such a
> reduction in damage that I think it's delivering the essence of what
> people are looking for regardless. That it might be possible in some
> cases to additionally avoid the overhead that comes along with any
> long-running query is a nice bonus, and it's great the design allows for
> that possibility. But if that's only possible with risk, heavy
> tweaking, and possibly some hacks, I'm not sure that's making the right
> trade-offs for everyone.
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?
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-02-27 05:08:35 | Re: Hot Standby query cancellation and Streaming Replication integration |
| Previous Message | Greg Smith | 2010-02-27 04:38:38 | Re: Hot Standby query cancellation and Streaming Replication integration |