Tom, As far as I can tell the source and destination dbs are SQL_ASCII, but I have to admit I'm not sure how to find out. When I dump just the schema for the cluster, I get the following create database statements in the dump: CREATE DATABASE neo WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'SQL_ASCII'; So it looks to me like it's using 'SQL_ASCII'. The dump I got from 7.? when I upgraded restored into 8.1 just fine. This is a dump from the 8.1. I've done some tests this morning where I just dump a table, create a temp database and try to restore the table into it. I've tried creating the db with different encodings and tried changing the line "SET client_encoding = 'SQL_ASCII';" in the dump to "SET client_encoding = 'UNICODE';", and they have the same results. So, long and short, I think that everything should be SQL_ASCII, but even when it is, I get the error. Thanks, Peter Darley -----Original Message----- From: Tom Lane [mailto:tgl@xxxxxxxxxxxxx] Sent: Tuesday, November 01, 2005 1:22 PM To: Peter Darley Cc: Pgsql-Admin Subject: Re: Can't dump and restore "Peter Darley" <pdarley@xxxxxxxxxxxxxxx> writes: > I'm having some trouble restoring data that was dumped from my database. > When I dump out a table (pg_dump -d neo -t question > question.tbl) and try > to restore it (psql -d temp -f question.tbl) I get errors on certain rows: > "psql:question.tbl:15861: ERROR: invalid byte sequence for encoding > "UNICODE": 0xe96520". This happens when I use SQL_ASCII or UNICODE as the > encoding. I didn't try any other encodings. Er, what is the encoding of the source database, exactly? Is it the same as the encoding of the destination database? SQL_ASCII disables all encoding checks, so it's entirely plausible that you would have byte sequences that are not legal Unicode in a SQL_ASCII database. If so, there's not much to do except manually clean up the bogus data. Also, if you're trying to restore into PG 8.1 from an older version, we've fixed some mistakes in the Unicode encoding checker, so there actually are differences in what the code will accept :-( regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
