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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-11-15 19:44:49 | Re: evil characters #bfef cause dump failure |
Previous Message | Tom Lane | 2004-11-15 17:09:24 | Re: cannot open segment 1 of relation .... No such file or directory |