Phoenix, how large (in total) is this database)? can you copy (cp -a) the data directory somewhere? I would do this just in case :-) regarding the manual recovery process: 1. you'll have to isolate corrupted table. you can do this by dumping all tables one-by-one (pg_dump -t TABLE) until you get the error. 2. find the record which is corupted... approach like this might work: select count(*) from the_corrupted_table where PK_column <= some_value. 3 .you should try to dump the table by chunks - skipping the corrupted row(s) if possible 4. if above method does not work, you can try manually hex-editing (zeroing) some bytes (with postgres shut down) to make dump work again. PS. obligatory note: 8.2.9 Release Date: 2008-06-12; 8.2.21 Release Date: 2011-04-18 seems like you were running almost three years without bugfixes. aside from fixing your current problem, I would first do the upgrade to avoid more corruption. 2011/4/18 Phoenix Kiula <phoenix.kiula@xxxxxxxxx> > > While doing a PG dump, I seem to have a problem: > > ERROR: invalid memory alloc request size 4294967293 > > Upon googling, this seems to be a data corruption issue! > > ( Came about while doing performance tuning as being discussed on the > PG-PERFORMANCE list: > http://postgresql.1045698.n5.nabble.com/REINDEX-takes-half-a-day-and-still-not-complete-td4005943.html > ) > > One of the older messages suggests that I do "file level backup and > restore the data". > http://archives.postgresql.org/pgsql-admin/2008-05/msg00191.php > > How does one do this -- should I copy the data folder? What are the > specific steps? > > I'm on PG 8.2.9, CentOS 5, with 8GB of RAM. The disks are four SATAII > disks on RAID 1. > > Thanks! > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
