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

From Bruce Momjian
Subject Re: Re: Hot Standby query cancellation and Streaming Replication integration
Date
Msg-id 201003021834.o22IYX529089@momjian.us
Whole thread Raw
In response to Re: Re: Hot Standby query cancellation and Streaming Replication integration  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Re: Hot Standby query cancellation and Streaming Replication integration
List pgsql-hackers
Bruce Momjian wrote:
> > 'max_standby_delay = -1' is really only a reasonable idea if you are 
> > absolutely certain all queries are going to be short, which we can't 
> > dismiss as an unfounded use case so it has value.  I would expect you 
> > have to also combine it with a matching reasonable statement_timeout to 
> > enforce that expectation to make that situation safer.
> 
> Well, as you stated in your blog, you are going to have one of these
> downsides:
> 
>     o  master bloat
>     o  delayed recovery
>     o  cancelled queries
> 
> Right now you can't choose "master bloat", but you can choose the other
> two.  I think that is acceptable for 9.0, assuming the other two don't
> have the problems that Tom foresees.

I was wrong.  You can choose "master bloat" with
vacuum_defer_cleanup_age, but only crudely because it is measured in
xids and the master defers no matter what queries are running on the
slave, and there is still the possibility for query cancel for long
queries.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Next
From: Josh Berkus
Date:
Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration