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)....so 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
<simon@2ndquadrant.com> 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 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