Re: Problems with pg_dump - Mailing list pgsql-general

From Ben Ramsey
Subject Re: Problems with pg_dump
Date
Msg-id FDEILMEPLBBHKOPONMBDEEGLDCAA.ben@eureka-interactive.com
Whole thread Raw
In response to Re: Problems with pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Problems with pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> Can you do "select * from pg_shadow" without errors?  How
> about pg_group and pg_database?

I can do all of these without any problems, but I think I've narrowed down
the culprit.  It seems that the error is generated off of (perhaps corrupt?)
columns in the database.  When I log into the database, I can "select *" on
each table.  For some tables, I get all the results.  For others, I get an
error.  For the tables generating errors, I further narrowed it down by
"select <column name>".  I can get data from most of the columns, but some
of them generate errors.  For example, a column with a timestamp datatype
gives me the following error:

     ERROR: floating point exception! The last floating point operation
     either exceeded legal ranges or was a divide by zero.

Thus, I can dump all tables that do not generate errors using
"pg_dump -ad --table <table name> <dbname>".  But I cannot dump the tables
with corrupted in this way.  I can, however, use \o (in psql) to specify a
file to which query output may be directed (and then run a query that
selects only the unaffected columns).  But this is not the desired course,
as it doesn't generate the INSERT statements.

So, I ask: How does one drop a column from a table so that I can drop the
affected column and then use pg_dump as normal?


pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Performance Problem
Next
From: Jeff Eckermann
Date:
Subject: Re: Getting Started in Postgresql