Re: pg_dump/pg_restore problem

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(at)illumen(dot)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
>