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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: cannot open segment 1 of relation .... No such file or directory
Следующее
От: Tom Lane
Дата:
Сообщение: Re: evil characters #bfef cause dump failure