Errors Generated From 'pg_dump' - Mailing list pgsql-admin

From Alter, Duane S
Subject Errors Generated From 'pg_dump'
Date
Msg-id 883C320C5AD07E4FB39E235E911F177F01493814@HC-MAIL11.healthcare.uiowa.edu
Whole thread Raw
List pgsql-admin

Hello,

Currently running Postgres v 8.0.3 on a RHEL AS4 production system (Kernel 2.6.9-42.0.2.ELsmp). Database is fairly large and growing, as such has vacuum and pg_dump scripted to run from cron nightly. A few days ago noticed the nightly dump filesize was roughly half its 'normal' size (288 MB gzip'ed,  down from ~ 500 MB gzip'ed). Ran our pg_dump script manually, received the following output:

pg_dump: ERROR: could not access status of transaction 1024987564
DETAIL: could not open file "/rtdb/data/pg_clog/03D1": No such file or directory
pg_dump: SQL command to dump the contents of table "attachments" failed: PQendcopy() failed.
pg_dump: Error message from server: ERROR: could not access status of transaction 1024987564
DETAIL: could not open file "/rtdb/data/pg_clog/03D1": No such file or directory
pg_dump: The command was: COPY public.attachments (id, transactionid, parent, messageid, subject, filename, contenttype, contentencoding, content, headers, creator, created) TO stdout;

The DB error log shows the following:

ERROR: could not access status of transaction 1024987564
DETAIL: could not open file "/rtdb/data/pg_clog/03D1": No such file or directory


File '03D1' doesn't exist in the pg_clog directory (22 total entries, 0000 thru 0015).  Searched for this error on the Net, found the "phantom pg_clog" to be fairly common and indicative of data corruption within the database; a bad tuple header / row association.  What is throwing me is the 'PQendcopy() failed'stanza,  with a whole table failing to process, not just a specific row.

The scripts that are called from cron are as follows
Vacuum:  /usr/local/postgres/bin/vacuumdb -U postgres --analyze rt3 -v >> /rtdb/logs/rtvacuum_`date +%Y%m%d` 2>&1
"pg_dump":  /usr/local/postgres/bin/pg_dump -U postgres -c --format=c rt3 | gzip > /rtdb/backups/rtdata-`date +%Y%m%d`.gz

The vacuum runs 15 minutes prior to the pg_dump script.

Any and all help on troubleshooting this issue and recovering the associated data is greatly appreciated.

                Thanks,
                Duane

Duane S. Alter
Health Care Information Systems
University of Iowa Hospitals and Clinics

pgsql-admin by date:

Previous
From: gpio Oxxce
Date:
Subject: Re: possible Bug in windows version ?
Next
From: Daniel Medina
Date:
Subject: Re: tabla pg_user Ayuda......