On Sun, Dec 2, 2012 at 1:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: >> On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'm confused. Are you now saying that this problem only exists in >>> 9.1.x? I tested current HEAD because you indicated the problem was >>> still there. > >> No, I'm saying the problem exists both in 9.1.x and in hypothetical >> 9.2.2 and in hypothetical 9.3, but not in 9.2.[01] because in those it >> is masked by that other problem which has just been fixed. > > I'm still confused. I've now tried this in both HEAD and 9.1 branch > tip, and I do not see any misbehavior. If I set recovery_target_time to > before the pg_stop_backup time, I get "FATAL: requested recovery stop > point is before consistent recovery point" which is what I expect; and > if I set it to after the pg_stop_backup time, it starts up as expected. > So if there's a remaining unfixed bug here, I don't understand what > that is.
I've reproduced it again using the just-tagged 9.2.2, and uploaded a 135MB tarball of the /tmp/data_slave2 and /tmp/archivedir to google drive. The data directory contains the recovery.conf which is set to end recovery between the two critical time points. https://docs.google.com/open?id=0Bzqrh1SO9FcES181YXRVdU5NSlk This is the command line I use to start recovery, and the resulting log output. https://docs.google.com/open?id=0Bzqrh1SO9FcEaTQ2QXhFdDZYaUE I can't connect to the standby to execute pg_xlog_replay_resume() because: FATAL: the database system is starting up Cheers, Jeff -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
