From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: invalid memory alloc request size |
Date: | 2011-12-27 22:37:28 |
Message-ID: | 4EFA48A8.7030604@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 27.12.2011 23:23, Merlin Moncure wrote:
> On Tue, Dec 27, 2011 at 4:07 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>> That's not likely. The corruption is usually the cause, when it hits
>> varlena header - that's where the length info is stored. In that case
>> PostgreSQL suddenly thinks the varlena field has a negative value (and
>> malloc accepts unsigned integers).
>
> If the problem truly went away, one likely possibility is that the bad
> tuple was simply deleted -- occasionally the corruption is limited to
> a tuple or two but doesn't spill over into the page itself -- in such
> situations some judicious deletion of rows can get you to a point
> where you can pull off a dump.
Or maybe the record is not read for some other reason ... maybe the
table is accessed in a different way and the corrupted column is not
checked. Or maybe it does not match the WHERE condition or something.
I've seen cases where the table was accessed sequentially and it was
failing (as the column was checked because of the WHERE condition), and
then it switched to index scan and it did not fail anymore (because it
was not necessary to check the column anymore).
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | saqib11 | 2011-12-27 23:11:46 | Kindly Please Help Me |
Previous Message | Thomas Kellerer | 2011-12-27 22:33:47 | Re: Detecting uncommitted changes |