From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: invalid memory alloc request size |
Date: | 2011-12-27 22:23:02 |
Message-ID: | CAHyXU0w72WvhiVTdD3_-8HDT_RophMU=gbg6-3eUvJzpSwJ8cA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Dec 27, 2011 at 4:07 PM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>>> Googling around, it sounds like this is often due to table corruption, which would be unfortunate, but usually seems to be repeatable. I can re-run that query without issue, and in fact can select * from the entire table without issue. I do see the row was updated a few minutes after this error, so is it wishful thinking that vacuum came around and successfully removed the old, corrupted row version?
>>
>> It also happens that 18446744073709551613 is -3 in 64-bit 2's complement if it was unsigned. Is it possible that -3 was some error return code that got cast and then passed directly to malloc()?
>
> 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.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2011-12-27 22:33:47 | Re: Detecting uncommitted changes |
Previous Message | Tomas Vondra | 2011-12-27 22:07:26 | Re: invalid memory alloc request size |