From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stuart Bishop <stuart(at)stuartbishop(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pgstattuple triggered checkpoint failure and database outage? |
Date: | 2009-03-31 04:10:55 |
Message-ID: | 301.1238472655@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Stuart Bishop <stuart(at)stuartbishop(dot)net> writes:
> On Tue, Mar 31, 2009 at 8:59 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What's the actual size of that relation now? Is it growing rapidly?
>> (I'm trying to figure out whether those writes *should* have succeeded,
>> or whether the block numbers were corrupt in memory.)
> I can't seem to find a file on disk named 11088101 or an entry in pg_class where relfilenode = 11088101.
> Are the allocated table oids always increasing? If so, I can pretty much guarantee that the missing relation was a temporary table or the index on the temporary table. It had a single integer column and maybe 50million rows.
The OIDs increase till they wrap around, so what this sounds like is a
problem with somebody fetching temporary-table blocks into shared memory
(where they should never be), and then things going wrong after the
owning backend drops the temp table (without having cleared out shared
buffers, which it won't do because it doesn't think it needs to). Can
you say what was the exact command(s) you were using with pgstattuple?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-03-31 04:20:20 | Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? |
Previous Message | Justin | 2009-03-31 04:03:08 | Re: string_to_array with empty input |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-03-31 04:14:22 | Re: can't load plpython |
Previous Message | Justin | 2009-03-31 04:03:08 | Re: string_to_array with empty input |