From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | Naoko Reeves <naokoreeves(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: invalid memory alloc request size 1765277700 Error Question |
Date: | 2012-02-24 18:43:16 |
Message-ID: | 23548.1330108996@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> writes:
> On Fri, Feb 24, 2012 at 10:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Naoko Reeves <naokoreeves(at)gmail(dot)com> writes:
>>> [ inconsistent behavior with a corrupted table ]
>> I think most likely some of these queries are using a corrupted index
>> and some are not --- have you looked at the EXPLAIN for each one?
>> It might be a good idea to turn off enable_indexscan and
>> enable_bitmapscan while poking at the table.
> Could it also be a corrupted toast table?
The toast table might well be corrupted, but that wouldn't explain the
variation in behavior when fetching the "same" row. I'm inclined to
think that Naoko has got more than one apparently-live row with the
same id value, as a result of corruption of xmin/xmax values or commit
hint bits. Not sure how to explain all the symptoms though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Prashant Bharucha | 2012-02-24 19:41:36 | Maxium Share Memory in Debian 64bit |
Previous Message | Willem Buitendyk | 2012-02-24 18:31:44 | Re: Upgrade to 9.1 causing function problem |