бд в юникоде. такое вот сообщение:

pg_restore: [archiver (db)] Error from TOC entry 2668; 0 111912 TABLE DATA post_prices postgres
pg_restore: [archiver (db)] COPY failed: ERROR: invalid byte sequence for encoding "UTF8": 0xc009
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
CONTEXT: COPY post_prices, line 18505

в итоге имеем пустую таблицу post_prices :(. что бы это значило и как бы этого избежать? сейчас мне нужно было перенести изменённую бд с одной машины на другую. к счастью скрипт изменений я сохранил - и сейчас я просто вместо переноса ту бд этим скриптом подправлю. но на будущее это не всегда можно будет сделать :(. или изменения чтобы сохранить нужна большая внимательность чем у меня есть :) - или иногда требуется поставить базу там, где её вообще ещё не было - и с данными реальными. т.е. тут это уже не прокатит :(. так что нужно с этим разобраться. помогите плз кто знает. там сами данные пролистать не реально - табличка эта одна весит как половина бд. собственно так я и заметил это - резко уменьшился размер дампа - почти в 2 раза :). и данные там тоже не возможно предположить какие - туда грузятся в оригинальном виде прайсы поставщиков, присылаемые в excel - т.е. может быть там что угодно. но раньше таких приколов не было. грузятся данные из excel odbcшным провайдером. там сам постгрес при установке создает датасурс "PostgreSQL UNICODE" - т.е. кажися с кодировками там должно быть всё честно - и было вот до этого момента. базу эту я регулярно раз наверное 5 в неделю дампил и поднимал из дампа - пару месяцев уже. первый раз такой случился ляпсус.
помогите плз разобраться с этой фигнёй. да - всё это под виндой делается.

ладно, если по другому попробовать: как в текстовом поле найти и зарубить invalid byte sequence for encoding "UTF8": 0xc009? есть правда подозрение, что такого там много. Вообще не оч я понял в чём проблема - везде эти данные нормально обрабатываются - кроме пгрестор :(. про
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
- это тоже брехня - я базу эту два месяца с дома на работу и обратно тягал - т.е. по2 раза на день дамп/рестор - и было всё нормально с клиентским энкодингом блин.
ещё подробность новая - как оказалось вирус этот сидит в прайсе одного поставщика - набраного руками в экселе 97-м :). именно из-за него вся запара. и теперь зараза эта распространилась на другую таблицу в бд - и теперь при ресторе не только прайсы поставщиков не восстанавливаются - но и ещё 2 таблицы и констрайнтов пара :(. и удалить теперь просто эти данные нельзя :(. и лечить как не знаю. помогите плз. а недоведи господи что-то с компом - и капец тогда вообще будет :(
ну хоть какие-то мысли, ну пожалуйста :(...
convert(from_encoding, to_encoding) - так блин не понятно from чего его конвертить...
или как в текстовом поле найти этот инвалидный байт секвенс? - попробовать чтоли - два вопроса - как - и скоко их там будет ещё...
или в каком направлении ещё можно подумать?

с перлом я совсем не дружу - чем дальше, тем больше понимаю что к сожалению :).
про -d -D - уже я тоже догадался. Токо тут что-то странное происходит с psql: он упорно не хотит вычитывать файл, заданый ключём \i. у него там почемуто хронический чёто-там аксес денаед - как-то так. как я не изголялся. ничего не понял. что бы это значило? а пгадмин почемуто тоже не хотит файл дампа открывать - не ругается и не показывает никак что его что-то в нём не устраивает - просто пустое окно там где текст должен быть. разбираться в причинах не хотелось - поэтому я изобрёл такую методику: открываю дамп сначала ноутпадом с указанием что это утф-8, потом копирую в окно пгадмина. он потом это дело нормально переваривает. такая блин методика монстрическая. а мне почти каждый день это делать - ну если не дадо - то как минимум оч желательно. надо блин срочно попроще что-то придумать. свои мысли пока закончились. может у кого какая мысля об этом проскочит - так вы её не прячьте - тут пишите :).

client - unicode - это кстати что конкретно? koi8r - или что?
server - utf8

это так на одной машине - дома. на работе посмотрю. сейчас у меня основные пробуксовки с поднятием дома дампа, сделанного на работе. на работе тоже поднимал этот дамп - всё те же симптомы. там видимо тоже как-то так.

да - а вообще проблемы начались с вгрузки в бд прайса одного - как позже выяснилось в excel 97 набраного руками. со многими другими проблем не было. блин нужно было его перед вгрузкой пересохранить в новом формате - думаю excel 2003 всё бы сам разрулил без меня. но теперь поздно - по нему теперь пошли заявки, резервы, ссылки на приход. вообще к учёту всё это отношения не имеет - так что в очень крайнем случае можно всё это грохнуть. однако не хочется терять история заказов и резервирования. она нужна. ну и вообще на будущее хотелось бы разобраться с полтергейстом этим.

это типа лирическое отступление :).
да - ну и что из этого - client/server-encoding? поставить pgclientencoding=unicode|koi8r - или что - не соображу? видимо нет же такой кодировки - unicode? или я что-то туплю...

в мане написано utf8 - alias unicode. т.е. что - получается везде утф8? и ещё там про автоматическую конверсию кодировок - utf8 -->> all supported encodings.

вообще я тогда не понимаю в чём проблема. получается сплошной ок и вери гуд - а чего оно выдрючивается - х его знает :(