Re: Errors regarding transporting database using pg_dump - Mailing list pgsql-general

From Tom Lane
Subject Re: Errors regarding transporting database using pg_dump
Date
Msg-id 7558.1254754322@sss.pgh.pa.us
Whole thread Raw
In response to Errors regarding transporting database using pg_dump  (Chun-fan Ivan Liao <ivan@ivangelion.tw>)
List pgsql-general
Chun-fan Ivan Liao <ivan@ivangelion.tw> writes:
> STATEMENT:  CREATE FUNCTION "system"(cstring) RETURNS integer
>             AS '/lib/libc.so.7', 'system'
>             LANGUAGE c STRICT;

This hack doesn't work any more --- not that it was ever considered
supported or recommended.  If you really need such a thing, I'd
suggest writing a plperlu or pltclu or plpythonu (according to taste)
wrapper around system().  But do you really need it, or is this just
cruft left over in your database from some playing around?  If the
latter, just ignore this error.

> ERROR:  value too long for type character varying(12)
> CONTEXT:  COPY stulist, line 46803, column STU_CNAME: "鷓埥(9debacdd)砆"

This one looks like it might be an encoding issue.  What database
encoding did you have in the old server, and did you reproduce it
in the new one?

[ ... counts characters ... ]  although frankly that looks like it'd be
more than 12 characters by *anyone's* accounting.  Peculiar.  Maybe the
dump file got mangled while being copied over?

            regards, tom lane

pgsql-general by date:

Previous
From: Stuart Bishop
Date:
Subject: Re: attempted to lock invisible tuple - PG 8.4.1
Next
From: Joshua Berry
Date:
Subject: Limiting the impact of schema additions/poor queries made by clients on production machines