Re: Summary and Plan for Hot Standby - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Summary and Plan for Hot Standby
Date
Msg-id 4B0605E0.6090308@dunslane.net
Whole thread Raw
In response to Re: Summary and Plan for Hot Standby  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Summary and Plan for Hot Standby
List pgsql-hackers

Joshua D. Drake wrote:
> On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote:
>   
>> On 11/15/09 11:07 PM, Heikki Linnakangas wrote:
>>     
>>> - When replaying b-tree deletions, we currently wait out/cancel all
>>> running (read-only) transactions. We take the ultra-conservative stance
>>> because we don't know how recent the tuples being deleted are. If we
>>> could store a better estimate for latestRemovedXid in the WAL record, we
>>> could make that less conservative.
>>>       
>> Simon was explaining this issue here at JPUGCon; now that I understand
>> it, this specific issue seems like the worst usability issue in HS now.
>>  Bad enough to kill its usefulness for users, or even our ability to get
>> useful testing data; in an OLTP production database with several hundred
>> inserts per second it would result in pretty much never being able to
>> get any query which takes longer than a few seconds to complete on the
>> slave.
>>     
>
> I am pretty sure that OmniTI, PgExperts, EDB and CMD all have customers
> that are doing more than that... This sounds pretty significant.
>
>   

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.

cheers

andrew


pgsql-hackers by date:

Previous
From: Emmanuel Cecchet
Date:
Subject: Re: Union test case broken in make check?
Next
From: Robert Haas
Date:
Subject: Re: operator exclusion constraints