I think you're correct, I did have another server replication off of this one, but could this cause the server to stay in recover mode? In the log below it has caught up but doesn't not leave recovery mode even after a restart of the service. 2016-03-07 16:04:52 UTC FATAL: the database system is starting up 2016-03-07 16:04:52 UTC LOG: restored log file "000000010000581D00000082" from archive 2016-03-07 16:04:53 UTC FATAL: the database system is starting up 2016-03-07 16:04:53 UTC FATAL: the database system is starting up 2016-03-07 16:04:54 UTC LOG: restored log file "000000010000581D00000083" from archive 2016-03-07 16:04:55 UTC FATAL: the database system is starting up 2016-03-07 16:04:55 UTC LOG: restored log file "000000010000581D00000084" from archive 2016-03-07 16:04:55 UTC LOG: consistent recovery state reached at 581D/84D5FD40 2016-03-07 16:04:55 UTC LOG: database system is ready to accept read only connections 2016-03-07 16:04:56 UTC LOG: unexpected pageaddr 581B/44000000 in log segment 000000010000581D00000085, offset 0 2016-03-07 16:04:56 UTC LOG: started streaming WAL from primary at 581D/84000000 on timeline 1 2016-03-07 16:04:56 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:56 UTC STATEMENT: unlisten * 2016-03-07 16:04:56 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:56 UTC STATEMENT: unlisten * 2016-03-07 16:04:57 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:57 UTC STATEMENT: unlisten * 2016-03-07 16:04:57 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:57 UTC STATEMENT: unlisten * 2016-03-07 16:04:57 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:57 UTC STATEMENT: unlisten * 2016-03-07 16:04:58 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:58 UTC STATEMENT: unlisten * 2016-03-07 16:04:58 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:04:58 UTC STATEMENT: unlisten * 2016-03-07 16:05:03 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:05:03 UTC STATEMENT: unlisten * 2016-03-07 16:05:06 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:05:06 UTC STATEMENT: unlisten * 2016-03-07 16:05:08 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:05:08 UTC STATEMENT: unlisten * 2016-03-07 16:05:08 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:05:08 UTC STATEMENT: unlisten * 2016-03-07 16:05:13 UTC ERROR: cannot execute UNLISTEN during recovery 2016-03-07 16:05:13 UTC STATEMENT: unlisten * Stephen Kuntz | Systems Administrator Pelmorex Media Inc. T: 905.829.1159 x1376 -----Original Message----- From: pgsql-admin-owner@xxxxxxxxxxxxxx [mailto:pgsql-admin-owner@xxxxxxxxxxxxxx] On Behalf Of MirrorX Sent: Monday, March 7, 2016 10:48 AM To: pgsql-admin@xxxxxxxxxxxxxx Subject: Re: WAL replay asking for very old WAL could it be that you have some other slave trying to replicate from this one (that was last built) and it has fallen behind and is asking for that old WAL file? -- View this message in context: http://postgresql.nabble.com/WAL-replay-asking-for-very-old-WAL-tp5891050p5891066.html Sent from the PostgreSQL - admin mailing list archive at Nabble.com. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
