From: | Selena Deckelmann <selenamarie(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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:26:00 |
Message-ID: | 2b5e566d0911192226m6c41509dqe511630bde2a00e4@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 20, 2009 at 11:14 AM, Josh Berkus <josh(at)agliodbs(dot)com> 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 don't think that's all that was discussed :)
Are you saying that it should not be committed if this issue still exists?
The point of getting Hot Standby into core is to provide useful
functionality. We can make it clear to people what the limitations
are, and Simon has said that he will continue to work on solving this
problem.
-selena
--
http://chesnok.com/daily - me
http://endpoint.com - work
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-11-20 06:47:53 | Re: Summary and Plan for Hot Standby |
Previous Message | Heikki Linnakangas | 2009-11-20 06:25:59 | Re: Summary and Plan for Hot Standby |