> 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
>
>