ERROR: MemoryContextAlloc
Hi all,
we encounter a big problem. PG 7.1.3 for a long time, tables working
perfect for months... Linux 2.4.3 or 2.4.10
When we dump our base we get things like :
ERROR: MemoryContextAlloc: invalid request size 4294967293
PQendcopy: resetting connection SQL query to dump the contents of Table
'identite' did not execute correctly.
After we read all the table contents from the backend, PQendcopy() failed.
Explanation from backend: 'ERROR: MemoryContextAlloc: invalid request size
4294967293
Some (small) tables dump correctly, but most don't.
identite is a small one (100K records) but won't dump although
CREATE TABLE identite2 as
SELECT * FROM identite;
works
pg_dump still can't dump either identite or identite2 table
Another strange thing :
\o /tmp/somefile
SELECT * FROM identite
\o
this pops the ERROR: MemoryContextAlloc...
but SELECT field1,field2,...lastfield works
Anyone has a clue ? We can't backup our production machines and
it's getting panicking if you see what I mean...
Thanks for *ANY* help
--
Jean-Christophe Boggio
cat@thefreecat.org -o)
Independant Consultant and Developer /\\
Delphi, Linux, Perl, PostgreSQL, Debian _\_V
Jean-Christophe Boggio <cat@thefreecat.org> writes:
When we dump our base we get things like :
ERROR: MemoryContextAlloc: invalid request size 4294967293
I think you have a corrupted data value in your identite table
(maybe more than one, but at least one). It's corrupted in a way
that doesn't prevent copying it to another table, but does prevent
converting it to text for output. (Possibly a corrupted compressed
string?)
Another strange thing :
\o /tmp/somefile
SELECT * FROM identite
\o
this pops the ERROR: MemoryContextAlloc...
but SELECT field1,field2,...lastfield works
Hard to believe --- are you sure you didn't miss a column?
Anyway, I'd suggest zeroing in on the row(s) with the problem by
doing "SELECT * FROM identite LIMIT n" for various n to identify
the location of the bad row, and/or selecting subsets of the columns
to figure out which column(s) contain bad data. Once you've found
the row you should be able to delete it.
regards, tom lane