Thread: pg_dump failes due to invalid memory request

Hi,

I just tried to call pg_dump for my database this evening, and it fails on one of my tables.
The error it gives in the log is:
ERROR:  invalid memory alloc request size 3221230573

So at this point what do I do?

What I have done:
I reindexed the table sucessfully, and it made no difference.
I tried grabbing all the rows around the last row that was sucessfully dumped through a select statment. That worked
sucessfully.

How do I test/fix this?
I am assuming something is corrupted but I am not sure how to figure out what. I have had nothing in the logs to
indicatea corruption. Now the only thing I can think of is that this particular table has 2 custom data types that are
bothtoastable. I am guessing that number indicates a bad header value at the beginning of one of the custom data types. 

Please help!

Thanks,
Morgan

"Morgan Kita" <mkita@verseon.com> writes:
> I just tried to call pg_dump for my database this evening, and it fails on one of my tables.
> The error it gives in the log is:
> ERROR:  invalid memory alloc request size 3221230573

This looks like a pretty standard data-corruption situation: you've got
a variable-width field somewhere with a ridiculous value in its length
word.  If you trawl the PG mail list archives you'll find plenty of
examples and discussions about how to triangulate on the bad row(s) and
get rid of them.

> Now the only thing I can think of is that this particular table has 2
> custom data types that are both toastable.

[ raised eyebrow... ]  Then it could also be a symptom of a garden
variety bug in your custom datatype code.  Have you tried getting
a stack trace from errfinish() to see exactly where the complaint
is being raised?

            regards, tom lane

> This looks like a pretty standard data-corruption situation: you've got
> a variable-width field somewhere with a ridiculous value in its length
> word.  If you trawl the PG mail list archives you'll find plenty of
> examples and discussions about how to triangulate on the bad row(s) and
> get rid of them.

Well last night I used a cursor to fetch 10000 rows at a time, and it sucessfully fetched all rows to a file. I don't
seemto be getting an error when I select the data, only from pg_dump... I will continue to check. 

>> Now the only thing I can think of is that this particular table has 2
>> custom data types that are both toastable.

> [ raised eyebrow... ]  Then it could also be a symptom of a garden
> variety bug in your custom datatype code.  Have you tried getting
> a stack trace from errfinish() to see exactly where the complaint
> is being raised?

I will defintely check this once I find the problem tuple(s).

Thanks,
Morgan