On Mon, Jun 2, 2014 at 6:40 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>
> Did you check whether all the necessary FPIs were generated? That'd be
> my very first suspect.
Really? Shouldn't only the last one matter? All the other ones will be
overwritten later by later full page writes anywys, no? Also, i
thought this was pretty much underlying infrastructure that would be
pretty hard to get wrong in just one call site.
I see a relatively few inserts that don't have backup blocks. The few
that do are preceded by another insert for the same block since the
last checkpoint redo pointer location. There is precisely one split
and it's shortly after the backup started but is a split to a
different right block from the one in the error.
> How many checkpoints are inbetween 334/90 and 339/65?
68 (though 13 of those are basically empty as the system was idle for a while)
> I guess you could make xlogdump dump the data from the backup blocks...
That's a clever idea. But it proved to be a little less useful than I
expected. Because it's a btree, not a heap I can't actually decipher
the items using bt_page_items() on plain byteas.
I am looking at the page headers and I'm a bit surprised to find the
LSN on the backup block images doesn't match the LSN of the record the
backup blocks are found in. I guess that makes sense since some AMs
will be generating records prior to even having touched the page in
question? Other than that there's not much to see in the page headers
:(
--
greg