Re: Summary and Plan for Hot Standby

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, jd(at)commandprompt(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Summary and Plan for Hot Standby
Date: 2009-11-20 06:55:53
Message-ID: 1258700153.27757.1323.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2009-11-20 at 06:47 +0000, Greg Stark wrote:
> On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > Right. The major use I was hoping for from HS was exactly to be able to run
> > long-running queries. In once case I am thinking of we have moved the
> > business intelligence uses off the OLTP server onto a londiste replica, and
> > I was really wanting to move that to a Hot Standby server.
>
> I think Simon's focus on the High Availability use case has obscured
> the fact that there are two entirely complementary (and conflicting)
> use cases here. If your primary reason for implementing Hot Standby is
> to be able to run long-running batch queries then will probably want
> to set a very high max_standby_delay or even disable it entirely. If
> you set max_standby_delay to 0 then the recovery will wait
> indefinitely for your batch queries to finish. You would probably need
> to schedule quiet periods in order to ensure that the recovery can
> catch up periodically. If you also need high availability you would
> need your HA replicas to run with a low max_standby_delay setting as
> well.

If I read this correctly then I have provided the facilities you would
like. Can you confirm you have everything you want, or can you suggest
what extra feature is required?

> This doesn't mean that the index btree split problem isn't a problem
> though. It's just trading one problem for another. Instead of having
> all your queries summarily killed regularly you would find recovery
> pausing extremely frequently for a very long time, rather than just
> when vacuum runs and for a limited time.
>
> I missed the original discussion of this problem, do you happen to
> remember the subject or url for the details?

December 2008; hackers; you, me and Heikki.

--
Simon Riggs www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-11-20 07:02:43 Re: Python 3.1 support
Previous Message Tom Lane 2009-11-20 06:51:39 Re: Syntax for partitioning