Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2007-12-31 at 12:33 -0500, Tom Lane wrote:
>> Actually, the other problem with that theory is that the slave swallowed
>> the file without complaint.
> No, it barfed. Mason showed us a recovery script, so it came from the
> slave.
No, it barfed on the *next* file. 422/58 it was fine with:
>>> 2007-12-20 04:11:43 CST () LOG: restored log file
>>> "000000010000042200000057" from archive
>>> 2007-12-20 04:13:09 CST () LOG: restored log file
>>> "000000010000042200000058" from archive
>>> 2007-12-20 04:14:40 CST () LOG: restored log file
>>> "000000010000042200000059" from archive
>>> 2007-12-20 04:14:40 CST () LOG: invalid info bits 0001 in log file 1058,
>>> segment 89, offset 0
>>> 2007-12-20 04:14:40 CST () LOG: redo done at 422/58FFEE38
The "invalid info bits" gripe is consistent with what Mason showed us from
the 0059 file, but there's nothing there complaining about the 0058 file.
(Sometime we oughta try to make these messages more consistent about
whether hex or decimal notation is being used...)
regards, tom lane