> On Fri, Apr 22, 2011 at 7:07 PM, <tv@fuzzy.cz> wrote:
> In the pg_dumpall backup process, I get this error. Does this help?
>
Well, not really - it's just another incarnation of the problem we've
already seen. PostgreSQL reads the data, and at some point it finds out it
needs to allocate 4294967293B of memory. Which is strange, because it's
actually a negative number (-3 AFAIK).
It's probably caused by data corruption (incorrect length for a field).
There are ways to find out more about the cause, e.g. here:
http://archives.postgresql.org/pgsql-hackers/2005-10/msg01198.php
but you need to have a pg compiled with debug support. I guess the
packaged version does not support that, but maybe you can get the sources
and compile them on your own.
If it really is a data corruption, you might try to locate the corrupted
blocks like this:
-- get number of blocks
SELECT relpages FROM pg_class WHERE relname = 'table_name';
-- get items for each block (read the problematic column)
FOR block IN 1..relpages LOOP
SELECT AVG(length(colname)) FROM table_name WHERE ctid >=
'(block,0)'::ctid AND ctid < '(block+1,0)'::ctid;
and once it fails remember the block ID (and restart - there might be more).
regards
Tomas