From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Greg Stark <gsstark(at)mit(dot)edu>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Hot Standby query cancellation and Streaming Replication integration |
Date: | 2010-03-01 20:04:41 |
Message-ID: | 4B8C1DD9.5000903@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/1/10 11:43 AM, Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>> Greg Stark wrote:
>>> For what it's worth Oracle has an option to have your standby
>>> intentionally hold back n minutes behind and I've seen that set to 5
>>> minutes.
>
>> yeah a lot of people are doing that intentionally...
>
> It's the old DBA screwup safety valve ... drop the main accounts table,
> you have five minutes to stop replication before it's dropped on the
> standby. Speaking of which, does the current HS+SR code have a
> provision to force the standby to stop tracking WAL and come up live,
> even when there's more WAL available? Because that's what you'd need
> in order for such a thing to be helpful in that scenario.
the "fast" recovery option should do this. You'd need some fast
reaction times, though.
However, this leaves aside Greg's point about snapshot age and
successive queries; does anyone dispute his analysis? Simon?
--Josh Berkus
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2010-03-01 20:30:20 | Re: function side effects |
Previous Message | Theo Schlossnagle | 2010-03-01 20:04:29 | double and numeric conversion |