Thanks for the patch Simon, but unfortunately it does not resolve the issue
I am seeing.  The standby still refuses to finish starting up until long
after all clients have disconnected from the primary (>10 minutes).  I do
see your new log statement on startup, but only once - it does not repeat.
 Is there any way for me to see  what the oldest xid on the standby is via
controldata or something like that?  The standby does stream to keep up with
the primary while the primary has load, and then it becomes idle when the
primary becomes idle (when I kill all the connections) it appears to
be current...but it just doesn't finish starting up

I'm not sure if it's relevant, but after it has sat idle for a couple
minutes I start seeing these statements in the log (with the same offset
every time):
DEBUG:  skipping restartpoint, already performed at 9/95000020

On Thu, Oct 27, 2011 at 7:26 AM, Simon Riggs <> wrote:

> Chris Redekop's recent report of slow startup for Hot Standby has made
> me revisit the code there.
> Although there isn't a bug, there is a missed opportunity for starting
> up faster which could be the source of Chris' annoyance.
> The following patch allows a faster startup in some circumstances.
> The patch also alters the log levels for messages and gives a single
> simple message for this situation. The log will now say
>  LOG:  recovery snapshot waiting for non-overflowed snapshot or until
> oldest active xid on standby is at least %u (now %u)
>  ...multiple times until snapshot non-overflowed or xid reached...
> whereas before the first LOG message shown was
>  LOG:  consistent state delayed because recovery snapshot incomplete
>  and only later, at DEBUG2 do you see
>  LOG:  recovery snapshot waiting for %u oldest active xid on standby is %u
>  ...multiple times until xid reached...
> Comments please.
> --
>  Simon Riggs         
>  PostgreSQL Development, 24x7 Support, Training & Services
> --
> Sent via pgsql-hackers mailing list (
> To make changes to your subscription:

Reply via email to