Michael,
Can I generalize that, if after step 4) page ( new page or old page) got written disk from buffer and crash happens between step 4) and 5) we always get
block corruption issues with Postgres which can only be recovered by setting zero_damaged_pages if we just have pg_dump backups and we are OK lose data in the affected blocks?
I am also looking at ways of reproducing the issue ? appreciate your advice on it ?
On Fri, Dec 9, 2016 at 12:01 PM, Michael Paquier <michael.paquier@xxxxxxxxx> wrote:
On Fri, Dec 9, 2016 at 9:46 AM, Sreekanth Palluru <sree4pg@xxxxxxxxx> wrote:
> Hi ,
> I am working on page corruption issue want to know if below scenario is
> possible
>
> 1) Insert command from client , I understand heap_insert is called from
> heampam.c
> 2) Let us say table is full and relation is extended and added a new block
> 3) Tuple is inserted into new page for the block RelationPutHeapTuple/hio.c
> 4) Later WAL record is inserted through recptr = XLogInsert(RM_HEAP_ID,
> info);
> 5) Then backend update the PageHeader with WAL LSN details PageSetLSN(page,
> recptr);
>
> If my server got crashed after step 4) is there a possibility that after
> postgres database restart I get below error when I access the relation or
> vacuum is run on this relation or taking backup through pg_dump ?
> ERROR: invalid page header in block 204 of relation base/16413/16900 ?
So the block is corrupted. You may want to move to another server.
> or
> Postgres can automatically recover the page without throwing any error ?
At crash recovery, Postgres would redo things from a point where
everything was consistent on disk. If this corrupted page made it to
disk, there is not much that can be done except restoring from a
backup. You could as well zero_damaged_pages to help here, but you
would lose the data on this page, still you would be able to perform
pg_dump and get back as much data as you can. At the same time,
corruption can spread as well as if that's a hardware problem, so you
are just seeing the beginning of a series of problems.
--
Michael
Regards
Sreekanth
