From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: page is uninitialized --- fixing |
Date: | 2009-06-09 20:17:19 |
Message-ID: | 28007.1244578639@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> 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.
It's probably too late to tell now, but I wonder if those pages actually
existed or were just a "hole" in the file. A perhaps-plausible
mechanism for them to appear is that the FSM spits out some ridiculously
large page number as being the next place to insert something into
pg_attribute, the system plops down a new tuple into that page, and
behold you have a large hole that reads as zeroes.
Another interesting question is whether the range began or ended at a
1GB segment boundary, in which case something in or around the
segmenting logic could be at fault. (Hmm ... actually 1GB is only
131072 pages anyway, so your "hole" definitely spanned several segments.
That seems like the next place to look.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-09 20:27:53 | Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX |
Previous Message | Tom Lane | 2009-06-09 20:04:27 | Re: postmaster recovery and automatic restart suppression |