Re: ERROR: invalid memory alloc request size 18446744073709551613

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Flaris Feller <flaris(dot)feller(at)gmail(dot)com>
Cc: "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: ERROR: invalid memory alloc request size 18446744073709551613
Date: 2020-06-22 16:54:38
Message-ID: 2080966.1592844878@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Flaris Feller <flaris(dot)feller(at)gmail(dot)com> writes:
> Em seg., 22 de jun. de 2020 às 12:33, Peter J. Holzer <hjp-pgsql(at)hjp(dot)at>
> escreveu:
>> On 2020-06-22 11:13:33 -0300, Flaris Feller wrote:
>>> When using Postgres 9.6.15 on "CentOS Linux release 7.5.1804 (Core)" on
>>> Intel x86_64 I noticed "invalid memory alloc request size" error at PostgreSQL
>>> logs.

>> That's 2**64 - 3. So probably the size of some object is (erroneously)
>> computed as -3 bytes.

Yeah. I don't recall the bit-level details offhand, but this is an
extremely common symptom of a corrupted length word in a variable-length
field.

The usual approach is to try to isolate which row or rows contains corrupt
data and then delete it. I'm not aware of any tools for doing that
automatically, but you can usually home in on a bad row by a process of
binary search, eg testing how many rows you can fetch without seeing the
error. Also "select * from mytab where ctid = '(m,n)'" is useful for
probing individual rows, once you get close to the problem area.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2020-06-22 17:00:55 Re: Netapp SnapCenter
Previous Message Paul Förster 2020-06-22 16:48:15 Re: Netapp SnapCenter