From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, 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 00:36:57 |
Message-ID: | 201002270036.o1R0avG03960@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Smith wrote:
> Bruce Momjian wrote:
> > Doesn't the system already adjust the delay based on the length of slave
> > transactions, e.g. max_standby_delay. It seems there is no need for a
> > user switch --- just max_standby_delay really high.
> >
>
> The first issue is that you're basically saying "I don't care about high
> availability anymore" when you increase max_standby_delay to a high
> value. Want to offload an 8 hour long batch report every day to the
> standby? You can do it with max_standby_delay=8 hours. But the day
> your master crashes 7 hours into that, you're in for a long wait before
> your standby is available while it replays all the queued up segments.
> Your 'hot standby' has actually turned into the old form of 'cold
> standby' just when you need it to be responsive.
Well, I think the choice is either you delay vacuum on the master for 8
hours or pile up 8 hours of WAL files on the slave, and delay
application, and make recovery much slower. It is not clear to me which
option a user would prefer because the bloat on the master might be
permanent.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2010-02-27 00:43:48 | Re: Hot Standby query cancellation and Streaming Replication integration |
Previous Message | Michael Glaesemann | 2010-02-27 00:30:16 | Re: Alpha4 Available Now |