evil characters #bfef cause dump failure
От | Christian Fowler |
---|---|
Тема | evil characters #bfef cause dump failure |
Дата | |
Msg-id | Pine.LNX.4.61.0411150335350.10091@leda.steelsun.com обсуждение исходный текст |
Ответы |
Re: evil characters #bfef cause dump failure
|
Список | 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 по дате отправления: