From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Chris Redekop <chris(at)replicon(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby startup with overflowed snapshots |
Date: | 2011-10-27 22:55:38 |
Message-ID: | CA+U5nM+g0gc+XdQ0JAN_hiywXaCT7P-3D-6ftPGDxfcCWGfQkQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 27, 2011 at 10:09 PM, Chris Redekop <chris(at)replicon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-10-28 01:29:15 | Re: pg_dumpall Sets Roll default_tablespace Before Creating Tablespaces |
Previous Message | Chris Redekop | 2011-10-27 21:09:40 | Re: Hot Standby startup with overflowed snapshots |