Re: PANIC: corrupted item lengths
От | Alvaro Herrera |
---|---|
Тема | Re: PANIC: corrupted item lengths |
Дата | |
Msg-id | 20090604135523.GA6577@alvh.no-ip.org обсуждение исходный текст |
Ответ на | PANIC: corrupted item lengths (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: PANIC: corrupted item lengths
Re: PANIC: corrupted item lengths |
Список | pgsql-hackers |
Simon Riggs wrote: > 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(). I tend to hate automatic zeroing of pages because there's no way to get the contents later for forensics. I would support your proposal if we had a way of saving the block elsewhere before zeroing it (say create a directory corrupted+zeroed similar to lost+found in the database dir and save it annotated with the OID of the table and the block number). The main problem I see with this is that if you don't immediately act to examine the data, some of the pg_clog files that you need to be able to read these files may be gone. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: