evil characters #bfef cause dump failure - Mailing list pgsql-admin

From Christian Fowler
Subject evil characters #bfef cause dump failure
Date
Msg-id Pine.LNX.4.61.0411150335350.10091@leda.steelsun.com
Whole thread Raw
Responses Re: evil characters #bfef cause dump failure
List pgsql-admin
I have been trying to track down the source of why my 7.4.5 database won't
reimport it's own dump ( http://archives.postgresql.org/pgsql-admin/2004-10/msg00213.php )

After much wrestling, it appears the hex byte sequence #bfef in a VARCHAR
column causes a truncated COPY line to be written (and thus the *entire*
COPY block fails). Exporting as inserts did not fix the problem either.

Any thoughts on why this might be so or how it can be avoided? Evil
thought of the day is if someone were to go around and paste this
multi-byte character in various websites' html forms it could cause a lot
of trouble.

Also, the behavior of the restore / psql import to complete the COPY
fields from the *following* line seems not good. It would be nice if the
missing columns could just be written as NULL's. 6 bad rows makes a 6 gig
dump worthless. Or perhaps an option to import each copy row in it's own
transaction so 5+ million copied rows don't fail for 6 bogus ones. Perhaps a
--this_is_an_emergency_so_please_do_everything_you_can_to_restore_as_much_as_possible
option.

If any of the core dev's want some small debug dumps I created, I'd be
happy to pass them on.

[ \ /
[ >X<   Christian Fowler      | spider AT viovio.com
[ / \   http://www.viovio.com | http://www.tikipro.org

pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: cannot open segment 1 of relation .... No such file or directory
Next
From: Tom Lane
Date:
Subject: Re: evil characters #bfef cause dump failure