Re: Re: Hot Standby query cancellation and Streaming Replication integration - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Re: Hot Standby query cancellation and Streaming Replication integration
Date
Msg-id 4B8AD6B3.1000300@2ndquadrant.com
Whole thread Raw
In response to Re: Re: Hot Standby query cancellation and Streaming Replication integration  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Re: Hot Standby query cancellation and Streaming Replication integration
List pgsql-hackers
Josh Berkus wrote:
> First, from the nature of the arguments, we need to eventually have both
> versions of SR: delay-based and xmin-pub.  And it would be fantastic if
> Greg Smith and Tom Lane could work on xmin-pub to see if we can get it
> ready as well.
>   

As I see it, the main technical obstacle here is that a subset of a 
feature already on the SR roadmap needs to get built earlier than 
expected to pull this off.  I don't know about Tom, but I have no 
expectation it's possible for me to get up to speed on that code fast 
enough to contribute anything there.  I expect the thing I'd be most 
productive at as far as moving the release forward is to continue 
testing this pair of features looking for rough edges, which is what I 
have planned for the next month. 

I'm not even close to finished with generating test cases specifically 
probing for bad behavior suspected after a look the implementation 
details--this is just what I came up with in my first week of that.  
Count me in for more testing, but out for significant development here.  
It's not what I've got my time allocated for because it's not where I 
think I'll be most productive.

> 2) A more usable vacuum_defer_cleanup_age.  If it was feasible for a
> user to configure the master to not vacuum records less than, say, 5
> minutes dead, then that would again offer the choice to the user of
> slightly degraded performance on the master (acceptable) vs. lots of
> query cancel (unacceptable).  I'm going to test Greg's case with
> vacuum_cleanup_age used fairly liberally to see if this approach has merit.
>   

I've been down that road and it leads quickly to the following 
question:  "how can I tell how old in time-based units an xid is?"  If 
there were an easy answer to that question, vacuum_defer_cleanup_age 
would already be set in time units.  It's the obvious UI to want, it's 
just not obvious how to build it internally.  Maybe I missed something, 
but my guess is that vacuum_defer_cleanup_age is already as good as it's 
going to get.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us



pgsql-hackers by date:

Previous
From: xu fei
Date:
Subject: full text search index scan query plan changed in 8.4.2?
Next
From: Dimitri Fontaine
Date:
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration