WAL ends before end time of backup dump

Version: 8.1.4

I am having a problem restoring one of my base backups. I took a
successful backup of the production DB already since this one, and this
is just a routine test, so it's fortunately not an emergency.

I think that I either have a corrupted base backup or corrupted WAL
segments, or maybe I hit some strange bug.

When I try to restore, I point recovery.conf to the full set of archived
WAL segments, and get the following result:

[snip]
LOG:  restored log file "00000001000000170000002B.004A3CAC.backup" from
archive
LOG:  restored log file "00000001000000170000002B" from archive
LOG:  checkpoint record is at 17/2B4CDC58
LOG:  redo record is at 17/2B4A3CAC; undo record is at 0/0; shutdown
FALSE
LOG:  next transaction ID: 41438715; next OID: 42280
LOG:  next MultiXactId: 1; next MultiXactOffset: 0
LOG:  automatic recovery in progress
LOG:  redo starts at 17/2B4A3CAC
LOG:  record with zero length at 17/2B6EACC8
LOG:  redo done at 17/2B6EAC84
LOG:  restored log file "00000001000000170000002B" from archive
PANIC:  WAL ends before end time of backup dump
LOG:  startup process (PID 88979) was terminated by signal 6
LOG:  aborting startup due to startup process failure

If I restore from the earlier base backup, which grinds slowly through a
week's worth of WAL segments, it stops at segment
00000001000000170000002B, like so:

[ snip ]
LOG:  restored log file "00000001000000170000002B" from archive
LOG:  record with zero length at 17/2B6EACC8
LOG:  redo done at 17/2B6EAC84
LOG:  restored log file "00000001000000170000002B" from archive
LOG:  archive recovery complete
LOG:  database system is ready
LOG:  transaction ID wrap limit is 1094453440, limited by database
"postgres"

If I restore from a later backup, everything works fine.

The thing that stands out to me about the base backup that doesn't work
is that it took several WAL segments to complete. Here's the .backup
file for the base backup that fails:

$ cat wal/00000001000000170000002B.004A3CAC.backup
START WAL LOCATION: 17/2B4A3CAC (file 00000001000000170000002B)
STOP WAL LOCATION: 17/397B7D64 (file 000000010000001700000039)
CHECKPOINT LOCATION: 17/2B4CDC58
START TIME: 2006-11-05 01:00:01 PST
LABEL: 20061105010001.27375.tar.gz
STOP TIME: 2006-11-05 01:14:03 PST

I noticed the 8.2beta3 included a fix for WAL replay, is that related?
Can someone link to the thread about that bug? I can't test newer
versions of postgres because all my other backups seem to work.

Basically, I'd just like to know what happened to prevent it in the
future. I am archiving to an NFS mount, I don't know whether that
carries a risk of corruption or not.

Regards,
    Jeff Davis