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

From Bruce Momjian
Subject Re: Hot Standby query cancellation and Streaming Replication integration
Date
Msg-id 201002270036.o1R0avG03960@momjian.us
Whole thread Raw
In response to Re: Hot Standby query cancellation and Streaming Replication integration  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Hot Standby query cancellation and Streaming Replication integration
List pgsql-hackers
Greg Smith wrote:
> Bruce Momjian wrote:
> > Doesn't the system already adjust the delay based on the length of slave
> > transactions, e.g. max_standby_delay.  It seems there is no need for a
> > user switch --- just max_standby_delay really high.
> >   
> 
> The first issue is that you're basically saying "I don't care about high 
> availability anymore" when you increase max_standby_delay to a high 
> value.  Want to offload an 8 hour long batch report every day to the 
> standby?  You can do it with max_standby_delay=8 hours.  But the day 
> your master crashes 7 hours into that, you're in for a long wait before 
> your standby is available while it replays all the queued up segments.  
> Your 'hot standby' has actually turned into the old form of 'cold 
> standby' just when you need it to be responsive.

Well, I think the choice is either you delay vacuum on the master for 8
hours or pile up 8 hours of WAL files on the slave, and delay
application, and make recovery much slower.  It is not clear to me which
option a user would prefer because the bloat on the master might be
permanent.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.comPG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard
drive,Christ can be your backup. +
 


pgsql-hackers by date:

Previous
From: Michael Glaesemann
Date:
Subject: Re: Correcting Error message
Next
From: Greg Stark
Date:
Subject: Re: Hot Standby query cancellation and Streaming Replication integration