PANIC: heap_update_redo: no block

Поиск
Список
Период
Сортировка
От Alex bahdushka
Тема PANIC: heap_update_redo: no block
Дата
Msg-id e0bf43760603182255q7eee6109n3f2afa0b10d3af71@mail.gmail.com
обсуждение исходный текст
Ответы Re: PANIC: heap_update_redo: no block  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-general
Hi.

Upon rebooting one of our main production database servers, we were
greeted with this:

(@)<2006-03-18 23:30:32.687 MST>[3791]LOG:  database system was
interrupted while in recovery at 2006-03-18 23:30:26 MST
(@)<2006-03-18 23:30:32.687 MST>[3791]HINT:  This probably means that
some data is corrupted and you will have to use the last backup for
recovery.
(@)<2006-03-18 23:30:32.688 MST>[3791]LOG:  checkpoint record is at D/1919D5F0
(@)<2006-03-18 23:30:32.688 MST>[3791]LOG:  redo record is at
D/191722C8; undo record is at 0/0; shutdown FALSE
(@)<2006-03-18 23:30:32.688 MST>[3791]LOG:  next transaction ID:
81148900; next OID: 16566476
(@)<2006-03-18 23:30:32.688 MST>[3791]LOG:  next MultiXactId: 1; next
MultiXactOffset: 0
(@)<2006-03-18 23:30:32.689 MST>[3791]LOG:  database system was not
properly shut down; automatic recovery in progress
(@)<2006-03-18 23:30:33.032 MST>[3791]LOG:  redo starts at D/191722C8
(@)<2006-03-18 23:30:33.035 MST>[3791]PANIC:  heap_update_redo: no block
(@)<2006-03-18 23:30:33.036 MST>[3790]LOG:  startup process (PID 3791)
was terminated by signal 6
(@)<2006-03-18 23:30:33.036 MST>[3790]LOG:  aborting startup due to
startup process failure

As far as i know the postgresql was shutdown properly before the
reboot (pg_ctl stop -m fast).  Though im not positive, I was just
brought in when they couldn't figure out why postgresql would not
start.  Any ideas as to how this happened or how to fix it?

Right now im copying over the database, and then going to try
pg_resetxlog.  Just to make sure, the only possible lost data are
things that are/would be in the xlog right?  So i dont need to go
looking at all the tables, just ones I know were modified then.

Are there any other solutions that dont involve possibly loosing data?
(Yes I know backups, unfortunately the last back up was about 2 hours
ago and is not as up to date as i would like)

Just curious, ive also been investigating pitr for instead of doing
backups every 2 hours.  If this problem were to surface when i was
using pitr as a backup solution, would all my data then be hosed (or
at least what pg_resetlog can not restore)?

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

Предыдущее
От: "Alain BAUDHUIN"
Дата:
Сообщение: pg_dump cross-version support
Следующее
От: Axel Straschil
Дата:
Сообщение: "\set AUTOCOMMIT off" has affect