On Thu, Oct 27, 2011 at 10:09 PM, Chris Redekop <ch...@replicon.com> wrote:
> hrmz, still basically the same behaviour. I think it might be a *little* > better with this patch. Before when under load it would start up quickly > maybe 2 or 3 times out of 10 attempts....with this patch it might be up to 4 > or 5 times out of 10...ish...or maybe it was just fluke *shrug*. I'm still > only seeing your log statement a single time (I'm running at debug2). I > have discovered something though - when the standby is in this state if I > force a checkpoint on the primary then the standby comes right up. Is there > anything I check or try for you to help figure this out?....or is it > actually as designed that it could take 10-ish minutes to start up even > after all clients have disconnected from the primary? Thanks for testing. The improvements cover specific cases, so its not subject to chance; its not a performance patch. It's not "designed" to act the way you describe, but it does. The reason this occurs is that you have a transaction heavy workload with occasional periods of complete quiet and a base backup time that is much less than checkpoint_timeout. If your base backup was slower the checkpoint would have hit naturally before recovery had reached a consistent state. Which seems fairly atypical. I guess you're doing this on a test system. It seems cheap to add in a call to LogStandbySnapshot() after each call to pg_stop_backup(). Does anyone think this case is worth adding code for? Seems like one more thing to break. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
