page is uninitialized --- fixing

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: page is uninitialized --- fixing
Date: 2009-06-09 16:00:02
Message-ID: 1244563202.15799.319.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


A couple of people in recent years have had a problem with "page X is
uninitialised -- fixing" messages.

I have a case now with 569357 consecutive pages that required fixing in
pg_attribute. We looked at pages by hand and they really are
uninitialised, but otherwise what we would expect for size, name etc..

Clearly this is way too many pages to be easily explainable.

Historically, this type of error has occurred mostly on servers that
have been through a recovery, so I have investigated it with that in
mind as a potential error source. Nothing found on that score, though
rsync is in use, as before.

One factor here is that temp tables are very heavily used. The size of
the pg_attribute table is *roughly* what I would expect, given the
frequency of temp table creation, numbers of cols used and lack of
vacuum.

The server did have non-ECC memory and there have been a few other
memory issues, but I'm still a little worried by this.

A completely separate client has twice had corrupted indexes on pg_class
in last 6 months, again a heavy user of temp tables. I've looked for
issues around the idea of all-temp catalog pages causing an problem, but
not seen anything as yet.

Any issues or ideas worth investigating?

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-06-09 16:07:35 Re: Multicolumn index corruption on 8.4 beta 2
Previous Message Albe Laurenz 2009-06-09 15:57:31 Problem with listen_addresses = '*' on 8.4beta2 on AIX