Tom, Scott,
Thank you very much for your advice and right questions that lead to me the
solution - In summary, I was able to identify and delete all corrupted data
with no data loss. Everything add up once I disabled index per Tom's advice.
Here is the detail report:
Review the data again in order
On Fri, Feb 24, 2012 at 4:01 AM, Naoko Reeves wrote:
> -- I have narrowed down the row
> SELECT * FROM table ORDER BY table_id OFFSET 526199 LIMIT 1 -- ERROR:
> invalid memory alloc request size 1765277700
Are you certain that offset 526199 is using both the same query plan
and doesn't produce t
Scott Marlowe writes:
> On Fri, Feb 24, 2012 at 10:09 AM, Tom Lane wrote:
>> Naoko Reeves 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?
>>
On Fri, Feb 24, 2012 at 10:09 AM, Tom Lane wrote:
> Naoko Reeves 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 t
Naoko Reeves 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 a
Curious: was there some sort of hardware issue or anything like that preceding
this issue?
Version: "PostgreSQL 8.4.6 on i386-apple-darwin, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370),
32-bit"
There was an hardware crash.
after that pg_dump fail
