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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-admin by date

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