Re: Endless recovery
От | Heikki Linnakangas |
---|---|
Тема | Re: Endless recovery |
Дата | |
Msg-id | 47B0207E.6090607@enterprisedb.com обсуждение исходный текст |
Ответ на | Endless recovery (Hans-Juergen Schoenig <postgres@cybertec.at>) |
Ответы |
Re: Endless recovery
|
Список | pgsql-patches |
Hans-Juergen Schoenig wrote: > this is he last info which was issued ... > > nothing in between ... > > during the rm_cleanup() nothing was logged into the logs. this is the > last log from today dawn: > > [2008-02-11 03:45:16 CET ]LOG: lost parent for block 8558565 > [2008-02-11 03:45:16 CET ]LOG: index 1663/16384/16578435 needs VACUUM or > REINDEX to finish crash recovery > [2008-02-11 03:45:16 CET ]DETAIL: Incomplete insertion detected during > crash replay. > [2008-02-11 03:47:54 CET ]LOG: database system is ready > [2008-02-11 03:47:54 CET ]LOG: transaction ID wrap limit is 1073742476, > limited by database "blids" > > that's where it finished, nothing else was logged between the "redo > done" and the last log messages I bet you've bumped into a bug in gist redo code, the cleanup phase shouldn't take long. It's just for completing any incomplete splits by inserting pointers to upper-level pages, and there shouldn't be more than a few of those active at any point in time. It looks like there's been quite a few changes to gistlog.c that haven't been back-patched. This one in particular might be relevant here: > revision 1.15 > date: 2006-04-03 17:45:50 +0100; author: tgl; state: Exp; lines: +15 -13; > Fix thinko in gistRedoPageUpdateRecord: if XLR_BKP_BLOCK_1 is set, we > don't have anything to do to the page, but we still have to adjust the > incomplete_inserts list that we're maintaining in memory. Teodor, what do you think? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: