ещё раз, повторю eddie : Вы work_mem уменьшили ? Вы знаете что это такое ? это сколько памяти можно использовать в запросе. причём work_mem при выполнение _одного_ запроса, в зависимости от запроса, может быть использовано целиком несколько раз. у Вас work_mem - один гигабайт, дамп осуществляется обычными sql командами, которые естественно могут использовать work_mem.

авторкакие тогда ограничения у PG-SQL на размеры данных, хранящихся в таблицах?это написано в документации, http://www.postgresql.org/docs/faqs.FAQ.html#item4.4

авторИ почему тогда получается, что сохранить в PG-SQL крупные блобы можно, но вот сдампить их для архива - не выйдет?потому что Вы некорректно настроили сервер - разрешили ему сожрать всё виртуальное адресное пространство процесса, и даже больше. любую базу можно сдампить если она не повреждена.


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

если хотите - можете посчитать, приблизительно:
32-х битный виндовс по умолчанию обычно выделяет 2 гигабайта под пользовательское адресное пространство в процессе. у Вас следующие настойки:

добавьте ещё сюда размер страниц под выполняемый код + данные (.exe .dll) + стек - пусть будет 100 мегабайт

итого ~ 1,8 гигабайта (если work_mem заполнится целиком только один раз, что совершенно не обязательно). у Вас осталось в запасе - 200 мегабайт. ещё раз выделить work_mem УЖЕ невозможно. то есть с текущими настройками Вам нужно сидеть и молиться что бы work_mem заполнялся целиком только максимум один раз на запрос, что совсем не обязательно. :)

А если вспомнить что адреса выделяются не по порядку, с нуля, а несколько "хаотично", например под .exe обычно выделяется адрес начиная с 0x00400000. а .dll отображается в адресное пространство не обязательно сразу после .exe или до. получается фрагментация адресного пространства которая "сожрёт" и гораздо больше тех оставшихся 200-т мегабайт просто под "дырки" между выделенными адресами. и выделить тот гигабайт work_mem одним куском - не получается...

всё тоже самое относится и к maintenance_work_mem, только она используется при восстановлении дампа (индексы, vacuum)

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

ImNeedHelpЯ специально увеличил ворк-мем в надежде, что дамп таки выгрузится.Вам надо не увеличивать, а уменьшать. Оно у Вас и так не влезает в два гигабайта.
ImNeedHelpНа компе кроме PG-SQL ничего нету, и кроме как pg-dump никто к серверу не обращается.это не имеет значения, если физической памяти не хватит - будет использован свап файл.
ImNeedHelpПотом добавил еще пару планок мозгов - в итоге их стало в общем зачете три гига с копейками - но и это не помогло.это не имеет значения. виндовс выделяет 2 гигабайта под страницы пользователя. Вы можете поставить хоть 8 планок физической памяти по гигабайту, это не изменит лимит в два гигабайта под страницы пользователя на процесс.

сервер перезапускали после изменения конфигурации ? если да - попробуйте вообще закоментировать work_mem и maintenance_work_mem, что бы значения по умолчанию остались.

авторМожет - какой-то фикс запустить или проверку? Есть какая-нибудь утилита?есть, если у Вас select * from problem_table и vacum full analyze работают без сообщений об ошибках (смотреть в логах) - значит скорее всего у Вас всё в порядке.

авторЗапускал pg-resetxlog.exe - но это очевидно из другой оперы и не помогает. о боже, это ещё зачем !? всю базу разнесли, или что-то осталось ? :)

если ничего не помогает - обращайтесь в 1С - пусть они разбираются что они там напатчили и почему _у них_ дамп не работает.


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

авторselect * from problem_table выдает клиенту out of memory for query resultвот этого по идеи не должно быть... хм...


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

скажите ещё пожалуйста, какое-то конкретное поле содержит большие блобы или оно размазано по всем полям bytea ?


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

удаётся выполнить ?


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

MBGВозьмите конфиг по умолчанию постгреса используемой вами версии, перезагрузитесь и запустите дамп. Если снова не получится, перезагрузитесь и дампайте сначала все таблицы, кроме проблемной, а потом отдельно проблемную таблицу. О результатах отпишитесь.

P.S. Перезагружаться под виндой обязательно.мне кажется бессмыслено мучить pg_dump если простой select * from problem_table выдает клиенту out of memory for query result... надо имхо сначала разобраться с этим. очень похоже на ошибку или повреждение базы...

поэкспериментировал с 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 была исправлена ошибка:
может быть с ней и была связана Ваша проблема ? у Вас какие настройки локали базы ?