Automatically force zero_damaged_pages while InRecovery?
От | Tom Lane |
---|---|
Тема | Automatically force zero_damaged_pages while InRecovery? |
Дата | |
Msg-id | 8212.1070131052@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: Automatically force zero_damaged_pages while InRecovery?
|
Список | pgsql-hackers |
We have seen a couple instances recently of WAL recovery failing due to the recently added code that validates a page header as soon as the page is read in, for example Olivier Prenant's crash report here: http://archives.postgresql.org/pgsql-hackers/2003-10/msg01505.php This failure is actually entirely pointless, because (AFAIK) any page that is brought in during WAL recovery is going to be overwritten in toto from the WAL log. So it would be safe to run WAL recovery with zero_damaged_pages enabled. Rather than expecting DBAs to think of that under the stress of a crashed-database situation, I propose that we do it for them: *** src/backend/storage/buffer/bufmgr.c.orig Fri Nov 21 12:41:31 2003 --- src/backend/storage/buffer/bufmgr.c Sat Nov 29 13:35:14 2003 *************** *** 231,237 **** if (status == SM_SUCCESS && !PageHeaderIsValid((PageHeader) MAKE_PTR(bufHdr->data))) { ! if (zero_damaged_pages) { ereport(WARNING, (errcode(ERRCODE_DATA_CORRUPTED), --- 231,237 ---- if (status == SM_SUCCESS && !PageHeaderIsValid((PageHeader) MAKE_PTR(bufHdr->data))) { ! if (zero_damaged_pages || InRecovery) { ereport(WARNING, (errcode(ERRCODE_DATA_CORRUPTED), Comments? regards, tom lane
В списке pgsql-hackers по дате отправления: