Skip site navigation (1) Skip section navigation (2)

Re: Help desperately needed: reoccurring invalid page

From: Mauri Sahlberg <Mauri(dot)Sahlberg(at)claymountain(dot)com>
To: Ian Westmacott <ianw(at)intellivid(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org, theporro(at)saunalahti(dot)fi,peikko(at)claymountain(dot)com
Subject: Re: Help desperately needed: reoccurring invalid page
Date: 2005-04-29 06:38:16
Message-ID: 4271D658.8050402@claymountain.com (view raw or flat)
Thread:
Lists: pgsql-admin
Hi,

Ian Westmacott wrote:

>Mauri, I'm no expert but I can tell you what I know.  We
>have experienced this same problem, and I asked a
>similar question not too long ago.
>
>-  This is probably due to some sort of I/O problem.  In
>   our case, it occurs very frequently on reboots, and
>   it appears to be related to dirty buffers not being
>   flushed out when the partition is unmounted.  Look
>   into a newer kernel, and/or newer/different
>   filesystem (we have seen this in various flavors
>   of the 2.4.6 kernel with XFS, JFS and EXT3).
>  
>
Uh. As our cheap server is a virtual machine under a virtuozzo
(http://www.sw-soft.com/products/virtuozzo/) I have no control over what
kernel to run or what filesystem to use. Nor has there been frequent
reboots. I have restarted the virtual server twice in 4 months and the
provider has done it once since production started. But as it might
still  be a filesystem problem (vzfs) I should try to find documentation
on vzfs to see if I can do something to increase its "reliability" or if
the provider can do that.

The client side did fail very frequently for a while due non mature
w-lan card driver and that might have caused the corruption that did not
got fixed properly by my inept attempts and still lurks around.

>-  If you have invalid page headers, you should take a
>   look at the run-time parameter zero_damaged_pages.
>   You can use this to fix up a table (losing the data
>   on the bad pages).
>
>  
>
Thanks I will try that.

>-  We have not found a way around the missing log file
>   problem.  This appears to end up locking some rows
>   forever.
>  
>
It seems to me that the best course for action for us would be: Zeroing
damaged pages. Dump every database excluding templates.
Shutdown. Remove provider's postgresql-rpms and install the latest rpms
on 7-series of Postgresql from Fedora legacy/pgfoundry.  Restore
databases. Manually merge changes from older backups that got zeroed. 
Upgrade client-side to the same version of postgresql as the server
side. Recompile libraries and applications. Startup. Backup. Increase
frequenzy of backups and hope for the best.


In response to

pgsql-admin by date

Next:From: Ryan J. CavicchioniDate: 2005-04-29 12:35:12
Subject: Re: Database Encryption (now required by law in Italy)
Previous:From: Michael FuhrDate: 2005-04-29 02:40:14
Subject: Re: why oh why procedure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group