Skip site navigation (1) Skip section navigation (2)

Re: Hot Standby query cancellation and Streaming Replication integration

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby query cancellation and Streaming Replication integration
Date: 2010-02-27 03:11:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Stark wrote:
> Eh? That's not what I meant at all. Actually it's kind of the exact
> opposite of what I meant.

Sorry about that--I think we just hit one of those language usage drift 
bits of confusion.  "Sit in the corner" has a very negative tone to it 
in US English and I interpreted your message badly as a result.  A 
Google search for images using that phrase will quickly show you what I 

> What I meant was that your description of the "High Availability first
> and foremost" is only one possible use case. Simon in the past
> expressed the same single-minded focus on that use case. It's a
> perfectly valid use case and I would probably agree if we had to
> choose just one it would be the most important.

Sure, there are certainly others, and as much as possible more 
flexibility here is a good thing.  What I was suggesting is that if the 
only good way to handle long-running queries has no choice but to 
sacrifice high-availability, which is is the situation if 
max_standby_delay is the approach you use, then the most obvious users 
for this feature are not being well served by that situation.  I would 
guess a large portion of the users looking forward to Hot Standby are in 
the "have an underutilized high-availability standby I'd like to use for 
offloading long running reports", and if there is no way to serve them 
well this feature is missing the mark a bit. 

You really can't do any better without better master/standby integration 
though, and as pointed out a couple of times here that was considered 
and just not followed through on yet.  I'm increasingly concerned that 
nothing else will really do though.

Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-27 03:12:38
Subject: Re: plpgsql: numeric assignment to an integer variable errors out
Previous:From: Bruce MomjianDate: 2010-02-27 03:09:26
Subject: Re: Testing of parallel restore with current snapshot

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group