Skip site navigation (1) Skip section navigation (2)

evil characters #bfef cause dump failure

From: Christian Fowler <spider(at)viovio(dot)com>
To: pgsql-admin list <pgsql-admin(at)postgresql(dot)org>
Subject: evil characters #bfef cause dump failure
Date: 2004-11-15 17:46:19
Message-ID: Pine.LNX.4.61.0411150335350.10091@leda.steelsun.com (view raw or flat)
Thread:
Lists: 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

Responses

pgsql-admin by date

Next:From: Tom LaneDate: 2004-11-15 19:44:49
Subject: Re: evil characters #bfef cause dump failure
Previous:From: Tom LaneDate: 2004-11-15 17:09:24
Subject: Re: cannot open segment 1 of relation .... No such file or directory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group