Re: Problems with pg_dump
От | Ben Ramsey |
---|---|
Тема | Re: Problems with pg_dump |
Дата | |
Msg-id | FDEILMEPLBBHKOPONMBDEEGLDCAA.ben@eureka-interactive.com обсуждение исходный текст |
Ответ на | Re: Problems with pg_dump (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Problems with pg_dump
|
Список | 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 по дате отправления: