Re: BUG #10432: failed to re-find parent key in index
От | Greg Stark |
---|---|
Тема | Re: BUG #10432: failed to re-find parent key in index |
Дата | |
Msg-id | CAM-w4HM3XEuAOSKeGLhBa0tV5Zwdv7Sx4Uo849a2-ivJZG8szA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #10432: failed to re-find parent key in index (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: BUG #10432: failed to re-find parent key in index
|
Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: