Re: right sibling is not next child

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: right sibling is not next child
Дата
Msg-id 26154.1144348014@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: right sibling is not next child  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: right sibling is not next child  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You weren't by any chance running with full_page_writes = off
>> were you?

> Yes we were.  Apparently I have misunderstood the implications of this.

So had we all :-(.  It just plain doesn't work in 8.1.*, and will be
disabled in 8.1.4 --- see discussion last week.  It might or might not
get resurrected in 8.2, depending on how messy it seems to be to fix.

Anyway, that explains your "heap_clean_redo: no block" failure.  I think
you're stuck risking a pg_resetxlog to try to get back into the
database.  If that results in a hopelessly corrupt database, we can try
modifying the WAL replay code to not consider this a fatal error, and
see if that produces anything we can use for debugging.  I'm glad this
isn't your only copy of the database ...

> There is a lot of data in the database which is confidential by law.
> I'd have to jump through a lot of hoops to get anyone to even consider
> letting me ship it off site.  If you're asking whether you could access
> in to our site, that might be arranged.

It sounds like the DB is too big to consider shipping anywhere anyway.
As long as you're comfortable doing stuff like pg_filedump and modifying
the code to get more debug info, we can proceed without getting into the
question of remote access.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: right sibling is not next child
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: right sibling is not next child