Re: invalid memory alloc request size - Mailing list pgsql-general

From Ben Chobot
Subject Re: invalid memory alloc request size
Date
Msg-id AD34DAB6-E1F8-421E-BA5D-D3BC53469D89@silentmedia.com
Whole thread Raw
In response to invalid memory alloc request size  (Ben Chobot <bench@silentmedia.com>)
Responses Re: invalid memory alloc request size
List pgsql-general
On Dec 26, 2011, at 8:08 AM, Ben Chobot wrote:

> Yesterday I had a problem on a 64-bit 9.1.1 install:
>
> # select version();
>                                                    version
> ----------------------------------------------------------------------------------------------------------------
> PostgreSQL 9.1.1 on x86_64-pc-linux-gnu, compiled by gcc-4.6.real (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, 64-bit
> (1 row)
>
>
> The logs showed this anomaly:
>
> 2011-12-25T19:33:18+00:00 pgdb2-vpc postgres[27546]: [74474-1] ERROR:  invalid memory alloc request size
18446744073709551613
> 2011-12-25T19:33:18+00:00 pgdb2-vpc postgres[27546]: [74474-2] STATEMENT:  SELECT * FROM "asset_user_accesses" WHERE
("asset_user_accesses"."asset_code"= 'assignments:course_141208' AND "asset_user_accesses"."user_id" = 618503) LIMIT 1; 
>
>
> Googling around, it sounds like this is often due to table corruption, which would be unfortunate, but usually seems
tobe repeatable. I can re-run that query without issue, and in fact can select * from the entire table without issue. I
dosee the row was updated a few minutes after this error, so is it wishful thinking that vacuum came around and
successfullyremoved 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
someerror return code that got cast and then passed directly to malloc()? 


pgsql-general by date:

Previous
From:
Date:
Subject: not-always-full vacuuming in 9.0 ?
Next
From: Thomas Kellerer
Date:
Subject: Detecting uncommitted changes