Joachim Wieland wrote:
> 1) With the current implementation they will see better performance on
> the master and more aggressive vacuum (!), since they have less
> long-running queries now on the master and autovacuum can kick in and
> clean up with less delay than before. On the other hand their queries
> on the standby might fail and they will start thinking that this HS+SR
> feature is not as convincing as they thought it was... Next step for
> them is to take the documentation and study it for a few days to learn
> all about vacuum, different delays, transaction ids and age parameters
> and experiment a few weeks until no more queries fail - for a while...
> But they can never be sure... In the end they might also modify the
> parameters in the wrong direction or overshoot because of lack of time
> to experiment and lose another important property without noticing
> (like being as close as possible to the master).
I assumed they would set max_standby_delay = -1 and be happy.
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2010-03-02 04:56:45|
|Subject: Re: Re: Hot Standby query cancellation and
Streaming Replication integration|
|Previous:||From: Tom Lane||Date: 2010-03-02 04:37:01|
|Subject: Re: Hung postmaster (8.3.9) |