Summary and Plan for Hot Standby

Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

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.

Joshua D. Drake


> 
> --Josh Berkus
> 
> 
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 17:17 -0500, Tom Lane wrote:
> Josh Berkus  writes:
> > So I'm in favor of committing part of the HS code even if there are
> > known failure conditions, as long as those conditions are well-defined.
> 
> If we're thinking of committing something that is known broken, I would
> want to have a clearly defined and trust-inspiring escape strategy.

If it is broken, we shouldn't commit it at all. Commit it to some
"other" git branch and call it, postgresql-alpha3-riggs-heikki if you
must but keep it out of core.

> 
> I agree with Heikki that it would be better not to commit as long as
> any clear showstoppers remain unresolved.
> 

Agreed.

Joshua D. Drake


> 			regards, tom lane
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

On Fri, 2009-11-20 at 16:40 +0900, Josh Berkus wrote:

> Yes.  I'm realizing that because of the highly techincal nature of the
> discussion and the language used few people other than you and Heikki
> are aware of the major issues which still need work.  It would be
> helpful if someone could post a summary of outstanding issues which
> didn't require prior extensive experience with the HS code to
> understand; possibly you could then get people trying to tackle just
> those individual issues.
> 

Yes I believe it is time for that. Those of us neck deep in production
loads would feel a lot better if we knew from a real world perspective
what the issue is.

Sincerely,

Joshua D. Drake


> --Josh BErkus
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering
If the world pushes look it in the eye and GRR. Then push back harder. - Salamander

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:

> - When switching from standby mode to normal operation, we momentarily
> hold all AccessExclusiveLocks held by prepared xacts twice, needing
> twice the lock space. You can run out of lock space at that point,
> causing failover to fail.

Proposed patch to fix that attached.

-- 
 Simon Riggs           www.2ndQuadrant.com

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby

Re: Summary and Plan for Hot Standby