On Fri, 2009-11-20 at 06:47 +0000, Greg Stark wrote: > On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
