поэкспериментировал с bytea и таки добился out of memory :)

1,5 Гб памяти + 2 Гб свап. при дампе 136 314 880 байтного bytea ~ два гигабайта съел сервер + ~ столько же - клиент и банально кончилась память. после увеличения свапа на два гигабайта - всё сдампилось успешно:

ImNeedHelp , маловероятно, но может быть у Вас со свап файлом проблема ?

ps: как я ни старался - залить в поле столько, что потом нельзя было сдампить, не получается. insert/copy/update - все отменяются с out of memory, правда у меня стандартный 8.3 без 1С


^{--
„Истина — это вовсе не то, что можно убедительно доказать, это то, что
делает всё проще и понятнее“ — Антуан де Сент-Экзюпери}

MBGХорошая иллюстрация к часто задаваемому вопросу о разумности хранения файлов в БД. Честно говоря, даже в голову не приходило, что оверхед может быть настолько огромным.бывает и хуже, имхо :)

вообще - да, он большой, так как при обработке bytea бинарные данные сериализуются через их строковое представление типа: E'\\000' - это например байт со значением ноль. то есть на один байт при сериализации в строку выделяется '\' '\' '0' '0' '0' - пять символов (байтов). получается в пять раз больше.

я честно говоря раньше думал что парсер запроса может обрабатывать входные строки по кусочкам, но судя по результатам экспериментов - получается что это не так. чудес не бывает :) и обновить кусок одного поля потом другого, потом вернуться опять к первому или начать выполнение до того как получена вся строка запроса от клиента - вряд ли возможно (можно конечно сделать такой сервер, что он будет писать входной запрос во временный файл, если он превышает определённый порог, но имхо это уже специфический изврат - текст запроса больше двух гигабайт :) ).
судя по размеру потраченной памяти - он пытается собрать строку сразу целиком за один раз, а так как ограничение на размер одного поля - 1 Гб (Maximum size for a field? 1 GB), видимо один гигабайт максимум он и может выделить на обработку одной строки (одного параметра запроса).
получается что приблизительный максимальный размер bytea бинарных данных = 1 Гб / 5 ~ 200 Мб.

Но тут есть неясности... во первых - не все байты обязательно паковать в пять байт их кода, те байты, значение которых совпадает с кодом ASCII символа, который можно вывести на экран - паковать не обязательно. Получается что можно передать и больше 200 мегабайт, хотя в общем случае - это зависит от содержимого (печатных символов в кодировке ASCII ~ 96 штук (из 255) )
но, например, залить avi файл размером 167 мегабайт в виде bytea мне не удалось...
2008-11-27 00:48:47 MSK ERROR: не хватает памяти
2008-11-27 00:48:47 MSK ПОДРОБНОСТИ: Ошибка при запросе размера 1073741823.
2008-11-27 00:48:47 MSK КОНТЕКСТ: COPY _reference59, строка 1: "1 1 true true 1 \N \N \N \N \N \N RIFFj\\367\\370\\011AVI LIST~"\\000\\000hdrlavih8\\000\\000\\000@\..."
2008-11-27 00:48:47 MSK КОМАНДА: COPY big._reference59 FROM STDIN

я экспериментировал с файлом размером 136 314 880 байт, заполненным случайными байтами с равномерным распределением по всему множеству значений, его текстовое представление в bytea занимало 483 470 156 символов (байт) - это с учётом печатных символов ASCII, если кодировать каждый байт (и печатный тоже), то он занимал бы соответственно 681 574 400 байт
этот файл успешно заливался через COPY TO в базу, я сделал шесть строк с ним + седьмая где это файл присутствовал в двух полях bytea:
вся эта таблица, после увеличения свапа, успешно дампилась pg_dump'ом

вообще, у меня хранятся файлы в рабочей базе, но в виде LO (Large Objects которые). у них есть кардинальные преимущества перед bytea:

- их не обязательно сериализовать в строку и по умолчанию насколько я понимаю это и не делается при передаче между клиентом и сервером, то есть никакого "в пять раз больше"
- с LO не обязательно работать целиком, как с одним значением. его можно читать кусочками как файл
- даже если очень хочется - его нельзя вставить в таблицу по значению, только как ID (ссылка на системную таблицу pg_largeobject), соответственно он не будет мешать обычным insert/select/update/delete
- его максимальный размер - 2 Гб
- он хранится разбитый на кусочки (по 131072 байта если не ошибаюь), таким образом при резервном копировании и восстановлении он не порождает никаких особогигантских многомегабайтных строк

да и сами файлы у меня небольшие - это отчёты в pdf максимум килобайт на 500

ps: но это всё лирика :) она не отвечает на вопрос автора топика - как так получилось что у него _в базе_ оказался bytea для обработки которого не хватает памяти. и что ему с этим делать... у меня пока не получается повторить эту проблему, но в принципе есть одна идея, может быть попробую попозже.

pps: кстати, можно ли быть уверенным что если в логах нет ругани на vacuum full и select, то таблица не повреждена ? может быть это всё же просто банально битая таблица ? %)


^{--
„Истина — это вовсе не то, что можно убедительно доказать, это то, что
делает всё проще и понятнее“ — Антуан де Сент-Экзюпери}

LeXa NalBatЁшps: но это всё лирика :) она не отвечает на вопрос автора топика - как так получилось что у него _в базе_ оказался bytea для обработки которого не хватает памяти. и что ему с этим делать... у меня пока не получается повторить эту проблему, но в принципе есть одна идея, может быть попробую попозже.попробуйте сделать выборку с другой машинки, на которой мало [доступной] памяти, чтобы не хватило памяти не серверу, а клиенту.

да как вариант - не сможет сделать дамп, но автор делает дамп насколько я понял на той же машине где и сервер. и памяти там по идеи хватает.
авторСегодня попробовал выгрузить дамп на машину с линуксом - но с тем же успехом, дамп обломился.
. . .
На компе кроме PG-SQL ничего нету, и кроме как pg-dump никто к серверу не обращается. Потом добавил еще пару планок мозгов - в итоге их стало в общем зачете три гига с копейками - но и это не помогло.3 Гб + ещё свап виндовый (он пока не ответил какого размера свап) + он пробовал и на другую машину делать дамп (правда не написал сколько там памяти)

LeXa NalBatможет почти вся память отдана серверу постгреса, клиенту остается недостаточно.может быть. надо ждать его ответа про свап :)
LeXa NalBatя подумал, что вы именно из-за этого советовали уменьшить work_mem.не совсем, work_mem у него был катастрофически большой - 1 Гб. если он весь используется да ещё + shared_buffers 700 Мб, то в адресном пространстве сервера просто не останется места под строку bytea. Всего в windows процесс может выделить ~ 2 Гб

ImNeedHelpСкопировал PGData на юниховую машину и попробовал натравить на проблемную таблицу перловую утилиту pgfsck
Она выдала много таких строк:
Может в самом деле - если эта утилита не врет - таблица побилась? Но почему тогда VACUUM/ANALIZE не выдает в логах сервера никаких ошибок и процедура отрабатывает успешно?а Вы останавливали сервер перед копированием ?

ImNeedHelpeddieкак раз таки похожий.
Хм...
Счаз попробовал сделать дамп с --encoding=UTF8 - дамп прошел нормально! Выгрузилось четыре с лишним гига, в логах постгря - никаких ошибок out of memory !значит это была просто ошибка :) надо Вам видимо обновляться до 8.2.11, в 8.2.8 была исправлена ошибка:
может быть с ней и была связана Ваша проблема ? у Вас какие настройки локали базы ?