From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | jd(at)commandprompt(dot)com |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Summary and Plan for Hot Standby |
Date: | 2009-11-20 06:25:59 |
Message-ID: | 4B063677.4040507@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
Agreed, it's the biggest usability issue at the moment. The
max_standby_delay option makes it less annoying, but it's still there.
I'm fine with it from a code point of view, so I'm not going to hold off
committing because of it, but it sure would be nice to address it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Selena Deckelmann | 2009-11-20 06:26:00 | Re: Summary and Plan for Hot Standby |
Previous Message | Tom Lane | 2009-11-20 06:19:06 | Re: Syntax for partitioning |