PANIC: corrupted item lengths

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема PANIC: corrupted item lengths
Дата
Msg-id 1244112527.23910.189.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответы Re: PANIC: corrupted item lengths  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: PANIC: corrupted item lengths  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I've seen a couple of *topic issues lately.

What seems strange about the various errors generated in bufpage.c is
that they are marked as ERRORs, yet are executed within a critical
section causing the system to PANIC.

There are a number of sanity checks that are made prior to any changes
taking place, so they need not generate PANICs. *topic is one such error
message but there are others. There is no need to take down the whole
server just because one block has a corruption. I'm not advocating that
corruptions are acceptable, but the server provides no way to remove the
corruption, which is a problem and server really should keep a better
grip on its towel in any case.

I would much prefer: 

* VACUUMs seeing these errors would perform as with zero_damaged_pages.
* other backends seeing those errors should just ERROR out. 

We can do this by having a new function: boolean PageIsValid() which
performs the sanity checks. This can then be executed by
heap_page_prune() prior to entering the critical section. That will then
be called correctly by both VACUUM and other code. VACUUM can then
optionally zero out the block, as is done with PageHeaderIsValid().

Votes?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



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

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: It's June 1; do you know where your release is?
Следующее
От: "Kolb, Harald (NSN - DE/Munich)"
Дата:
Сообщение: Re: Synchronous replication: status of standby side