Search Postgresql Archives

Re: invalid memory alloc request size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27.12.2011 18:34, Ben Chobot wrote:
> 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 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).

Some time ago I've written an extension that might help you locate
where's the actual issue (which block / row / field) and Heikki did some
review about a month ago so there's a change it might work. It's
available here

  http://github.com/tvondra/pg_check

Let me know in case of any issues.

regards
Tomas

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux