Re: pg_dump/pg_restore problem - Mailing list pgsql-admin

From adey
Subject Re: pg_dump/pg_restore problem
Date
Msg-id 1c66bda80610052203y3cd23b1dh7246666e124d8c22@mail.gmail.com
Whole thread Raw
In response to pg_dump/pg_restore problem  ("Benjamin Krajmalnik" <kraj@illumen.com>)
List pgsql-admin
I had a similar experience when we upgraded from 7.4 to 8.1.4.
When we attempted the restore in 8.1.4 / UTF8, it failed and told us the offending row. We edited the original database to correct the data and retried. There were several ofending rows, but fortunatley for the exact same value, so we could search the dump, find all the rows (about 6 of them), correct the original database, pgdump, and restoer successfully.
 
Our problem was the original database was sql_ascii and didn't care what was loaded (?), whereas 8.1.4 was more strict.

 
On 10/6/06, Benjamin Krajmalnik <kraj@illumen.com> wrote:
I have a database which has UTF8 encoding enabled (why?  I am really not
sure why I did tihs other than the source of the data is windows and I
had some issues with characters > ascii 128 being sent across from some
of the Windows event logs).
The problem which I am having is as follows:

The data is passed via the ODBC driver to a stored procedue, and it made
it successfully into the tables.
I can create a pg_dump without any problem, but pg_restore is giving the
following error:

pg_restore: ERROR: invalid byte sequence for encoding "UTF8": 0x80

CONTEXT: COPY tblksalerts, line 22736

I have tried running pg_dump changing the encoding to Latin1 and Latin9.
When creating the dunp, it is giving an error that there is no
equivalent in the character set.
The problem is that, as it stands, pg_dump/pg_restore cannot be used to
easily backup/restore.
In the past, I perfrmd singe table dumps and ran them so I could
identify which line was the problem, went back to the database, deleted
the offending line, and so forth, but this is a very long process.

I was initially runnin 8.1.2.  I am now running 8.1.4.  I was hoping
that 8.1.4 would alleviate the problem (since some encoding issues were
addressed).

Any ideas how to easily identify the offending rows and remove them
easily?

I need to move the database to a new server with higher performance, and
this is currently a sticking point.





---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

pgsql-admin by date:

Previous
From: "Benjamin Krajmalnik"
Date:
Subject: Re: pg_dump/pg_restore problem
Next
From: Jim Nasby
Date:
Subject: Re: Disk space consumed by pk not returned after vacuum or reindex