| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | 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:38:38 |
| Message-ID: | 4B88A1CE.1070906@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark wrote:
> But if they move from having a plain old PITR warm standby to having
> one they can run queries on they might well assume that the big
> advantage of having the standby to play with is precisely that they
> can do things there that they have never been able to do on the master
> previously without causing damage.
>
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.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aidan Van Dyk | 2010-02-27 04:53:48 | Re: Hot Standby query cancellation and Streaming Replication integration |
| Previous Message | Greg Smith | 2010-02-27 04:31:12 | Re: Hot Standby query cancellation and Streaming Replication integration |