On Sun, Dec 2, 2012 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> On Sat, Dec 1, 2012 at 1:56 PM, Tom Lane <tgl@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