Исходные данные :
КА 1.1.107.4 с мелкими доработками
Платформа 8.3.9.2170
СУБД Postgres Pro 9.4

Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .
Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.

Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :

pg_dump: Ошибка выгрузки таблицы "config": сбой в PQgetResult().
pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р'Р?Р?:  invalid memory alloc request size 1174829507
pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified,attributes, datasize, binarydata) TO stdout;

Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) - результат тот же, pg_dump не может нормально создать архив.

При постановке конфы обратно на поддержку архивация начинает работать нормально.

Как можно решить проблему?

я сегодня проверю вариант с большой конфигой по размеру (ка_2.4) на субд постгри и сервером на винде - сглючит или нет - проверю. Не знаю только получится ли протестить, если сервер для субд будет линуксовый... долго такое городить и профита не будет чисто поэкспериментировать и прокачать экспу разве что :-)

100 гигов, полёт нормальный.
SET PGPASSWORD=12344321

"C:\Program Files\PostgreSQL\10.3-2.1C\bin\pg_dump.exe" --host localhost --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --section pre-data --section data --section post-data --encoding UTF8 --verbose --file "D:\1cBackupNew\BUH_%date:~6,4%-%date:~3,2%-%date:~0,2%.backup" "BUH"

(50) а размер выгруженной одной только CF из этой базы какой?

(50) BUH ? - это же вероятно конфигурация БП какая-то?

(51) не проверял размер CF, БП30

(53) ну дык... с этими конфигами проблем нет, не было и не будет - про такие никто и не говорит.

(54) +100500

Вырезал из конфигурации несколько макетов ненужных драйверов.
cf сократил до 0,98 Гб. Но проблема с архивацией осталась.

(56) полностью снятие с поддержки (чтоб конфа была 600мб) тоже не помогает?

(56) а какую теперь ошибку пишет?

(58) Ту же самую.

(57) Этот вариант на крайний случай. Боюсь проблем с обновлениями.

(59) ???  invalid memory alloc request size 1174829507

(61) Да. Только циферки немного другие , поскольку на демобазе эксперименты ставлю.

просто для теста пг_дамп с
--exclude-table-data=public.config
пройдет?

(63) так архивация проходит без ошибок.

(64) гугл упорно говорит, что таблица битая. Я бы уменьшил ее еще, но значительно - до 500мб, например, и еще раз пг_дамп. Это подтвердит битая или нет

можно предположить, что источником ошибки и вовсе окажется некий конкретный объект метаданных, только сколько раз надо провернуть все-все-все манипуляции, чтоб найти такой объект. Причем, сбоить этот объект начинает в процессе клонирования конфиги поставщика в подкопию основной ЦФ-конфиги

постгре под виндой чтоли?

(65) Ставлю конфу на замок , или снимаю ее с поддержки - проблема уходит.

(67) см (24)-(31) - судя по всему такая же проблема возможна и под linux.

(69) тогда бы гугл знал о ней, 1гб сейчас не то чтобы много

(70) уже знает - в (44) (46) есть ссылки.

(71) извини, но это ссылки практически такого уровня, как на ветки на нашей же мисте

(71) вероятно они твои)
https://pgconf.ru/media/2018/02/14/DBeaver_PgConf-Russia-2018.pdf
будешь дальше копать или альтернативу искать?

(66) Похоже ты прав.
Развернул демоконфу КА2, включил возможность изменения - в результате  cf размером 1,2 Гб.

Архивация проходит без проблем.

Такая же проблема. dt делается. в копию серверную(Postgres pro 9.6) не грузится, ругается на память, а в файловую загрузился. Пытаюсь определить проблемный объект в метаданных. Попутно попробую в mssql 2008 загрузить dt.

(75) А я бы просто оставил базу с полностью снятой с поддержки, а обновления заготавливал по мере необходимости из файлового режима. Какая разница, если развернута тестовая копия и завершить процедуру обновления все равно нужно только на тестовой, а затем уже из тестовой забирать CF и обновлять продакшн базу сравнением/объединением.

(76) как сейчас решение да, но причина явно не устранена. попробую 107.5 накатить на файле и перенести на серверную.

В MsSQL действительно все загружается без ошибок. Проблема на стороне Postgres, попробую покопать настройки. Ни у кого нет опыта тонкой настройки? Не хочется верить, что Postgres настолько не продуман.

в релиз КА 1.1.107.5 этот косяк не убрали.

(78) никто и не заставляет. Только две конфиги КА 1.1 и УПП 1.3 - с остальными проблем нет. с КА 2.4 тоже проблем нет.

(79) этому косяку уже много лет.

(80) Но воспроизводится он только на демоконфигурациях версий 1.1.107.х.

Раньше была проблема на 32-ух битных версиях PostgreSQL, не хватало им памяти для больших конфигураций. Приходилось снимать с поддержки  конфу, чтобы работать.  С появлением 64-битной проблема ушла.
И вот опять что-то похожее.

(0) Какая операционная система?

(83) вин

(84) Ты не автор. "вин" бывает разный.

(83) win7, win10, win2008r2

Насколько я разобрался 1С пихает файл конфигурации в поле. Поле имеет ограничение 1 Гб. Размер конфы закрытой для ред. и снятой с поддержки не превышает 1 Гб, а частично дописанная превышает. 1С рекомендует (прочитал на форуме SQL) снимать с поддержки полностью или использовать pg_basebackup. Снял на тестовой с поддержки - дамп отработал без ошибок.

(87) см (74)

(87) Просто рекомендация 1С не совсем честная. Если снять конфу КА 1.1 с поддержки или УПП 1.3 с поддержки, то проблема действительно пропадает. Однако, есть другие конфы, с которыми этой проблемы в принципе нет - см (74),
а так же и другие.

(89) и решения от 1с скорее всего не дождемся. Работу с данными в этом случае организует кластер серверов 1с? имею в виду структуру таблиц.

(87) На каком варианте остановился?

(87)В тему: те же проблемы с УПП 1.3.112.4 на pg 9.6:
-при архивировании средствами pg - описанная выше ошибка
-при обновлении - вылетает

При анализе выяснилось, что ошибка возникает с таблицей config (конфигурация БД), при обработке определенной строки таблицы, подробности ниже.
1. Просмотрел таблицу config, поля: filename (строка), creation (датавремя), modified(датавремя), attributes(целое), datasize(целое), binarydata(bytea).
2. Строк 34017.
3. Сумма размера бинарных полей примерно 98% размера файла .cf (остальное занимают оставшиеся поля), т.е. в binarydata хранится конфигурация.
4. Проверил: для любой строки размер binarydata не более 100МБ. Кроме одной, там размер binarydata 555МБ. И именно в этой строке возникает ошибка. Выяснил, что в данной строке, в одном поле хранится конфигурация поставщика.
5. Поэтому при снятии с поддержки или запрете изменений (замок) ошибка исчезает, т.к. при этом удаляется строка по п.4.
Суммируя вышеизложенное: максимальный размер данных, внесенных в ОДНО поле - 0,55ГБ (см. п.4.), что не дотягивает до озвученного лимита объема данных в ОДНОМ поле 1ГБ.

Вывод: либо лимит объема ОДНОГО поля около 0,5ГБ, либо причина в другом.

Пробовал играть настройками конфигурации pg (размеры буферов памяти и т.п.) - ошибка не исчезла.

(92)Кстати, и обычный select средствами pg вызывает эту же ошибку, если в его результате содержится поле Binarydata с конфигурацией поставщика (555МБ) - еще одно подтверждение что ограничение 1ГБ ни при чем.

(93) да. конфа ка2 нормально переносит снятие с замка.

(0) ровно та же проблема у меня была с УПП в 2012 году - с той же ошибкой pg_dump грохался. Стабильность - признак мастерства, чо... Сколько лет прошло, а ничего не меняется.

(95) Так поди все на форумах пошушукались и разработчикам никто не отписал.

shared_buffers = 512Mb ?

(96) отписывались. Я помню об этих глюках примерно с 2011-2012 годов. Когда это поперло, то начали откладывать на ИТС полные дистрибы КА 1.1 и УПП 1.3 , т.к. реально был всплеск обращений, что не проходит процедура обновления конфиги апдейтами.

(97) shared_buffers = 768MB

(96) Я две недели назад написал на v8@1c.ru.
Отписались, что проблема передана разработчикам, и, пока, все.

Извиняюсь за многословие.
Простой эксперимент.
createdb test; psql test
В базе создаем таблицу
create table config(id int, bindata bytea);
и грузим в нее что-нибудь(неважно что, какой-нибудь файл)
insert into config values (1, pg_read_binary_file('_input/tstf.tgz'));
Все хорошо загрузилось, без ошибок.
Смотрим размер бинарной строки select octet_length(bindata) FROM config;
octet_length
--------------
    668411047                 размер загруженного файла в байтах
(1 row)

После этого пытаемся использовать pg_dump для создания выгрузки
pg_dump -F c -b  -f test.backup test
Результат — такая же ошибка, как и у автора темы
invalid memory alloc request size 1336822097   -  число, равное длина_бинарной_строки * 2 + 3

Далее, опять psql test
Смотрим, можно ли командой copy выгрузить таблицу config в файл
copy config to '/home/postgres/config.tbl';
Нет, нельзя, возникает та же ошибка.
В документации видим, что у команды copy есть параметр формата чтения/записи
данных binary, пробуем - copy config to '/home/postgres/temp2/config.tbl' with binary;
Ошибки не возникает, файл создается того же размера, что и бинарная строка.
Если размер бинарной строки, скажем, 350 МБ, то ошибки не возникает.

(101) круто!

А вот интересно (раз пошла такая пьянка - режь последний огурец), почему такого вида траблы нет, когда конфигурации не равны КА 1.1 или УПП 1.3 , например, КА 2 какая-то ?

(99) Но он же хочет больше "invalid memory alloc request size 1 174 829 507"
Может в этом дело?

(101) Урра ошибка не в 1С а в PostgreSQL так?

(104) нет. Пост собственно о том, что платформа 1С как-то криво и неоднозначно прописывает в базу конфигу Поставщика

Сервер для выполнения команды copy пытается выделить память, натыкается на ограничение в 1 GB и выдает ошибку.
< 2018-11-08 10:53:02.140 MSK >LOG:  00000: statement: copy config to '/home/postgres/config.tbl';
< 2018-11-08 10:53:02.140 MSK >LOCATION:  exec_simple_query, postgres.c:940
< 2018-11-08 10:53:02.513 MSK >ERROR:  XX000: invalid memory alloc request size 1336822097
< 2018-11-08 10:53:02.513 MSK >LOCATION:  palloc, mcxt.c:858
< 2018-11-08 10:53:02.513 MSK >STATEMENT:  copy config to '/home/postgres/config.tbl';

(105) Тоже верно, не учли особенностей постгрес и лимитов на одну запись.
Точнее учли но не догадались что при выгрузке бинарного поля оно каким то хитрым образом конвертится и занимает чуть более чем в 2 раза памяти.

(107) все бы ничего, но почему-то в других конфигах с этими примерно размерами траблы не возникает

з.ы. я уже одно и тоже повторяю :-)

(101) Снимаю шляпу. Я был уверен что эта фича-бага как-то так воспроизведется. Но вы меня опередили)

(109)Просто интересно стало.
(108)Может в более новых конфигурациях и стали учитывать. Не превышать размер конфы поставщика выше определенного значения.

(0) Хорошо бы проверить повторится ли эта ошибка на демобазе с разрешёнными изменениями и отключённым режимом совместимости. Возможно, что из-за активного режима совместимости платформа не использует какой-нибудь трюк для обхода этой проблемы.

(111) на демобазе все воспроизводится.

ansh15, а тебе удается восстановить табличку config из файла после COPY ... binary?


COPY public.config (id, bindata) FROM '/var/lib/postgresql/copy.test' with binary;

У меня вызывает крах сервера ИЛИ "Ошибка при запросе памяти (850672995 Б)"

(102) возможно, там либо этот объем меньше, либо как-то изменен формат хранения, чтобы в одном поле одной строки столько не хранилось. Собственно, в (105) вы пишете как раз об этом

(108) "примерно" здесь не сработает, нужно сделать запрос и посмотреть размер. Скорее всего, в новых конфигурациях каким-то образом обошли критический размер поля, а в старых это либо оказалось трудоемко, либо просто поленились связываться с этим. Либо третий вариант - обошли, но в сочетании новая платформа/новая конфигурация.

(115)Вероятнее всего дело в объеме данных.
Формат хранения конфигурации поставщика поменять - это ж нужно платформу допиливать, так?

(113) Да, в пустую таблицу.

(116) здесь может быть сочетание особенностей платформы и особенностей файла конфигурации. Т.е. что постарше хранят так, а что поновее - по-другому.

(118) +100500 :-)
вот у меня абсолютно такое же впечатление - сочетание особенностей

Возьму на себя смелость описать техническую причину проблемы.
1. У PG давным-давно сложилось, что размер буфера памяти для работы со строками не может превышать 1Гб.
2. pg_dump развёртывает бинарные строки в текст (под 1 байт бинарных данных отводится 16 бит (2 байта) текстовых данных). Таким образом размер данных удваивается.
3. Конфигурация в базе хранится одной бинарной строкой. Как только ее размер перевалит за ~0.5Гб.  pg_dump не сможет ее сохранить, это и приводит к ошибке описанной в первом посте.

Что можно сделать.
1. Использовать pg_basebackup https://its.1c.ru/db/metod8dev#content:5947:hdoc
2. Перекомпилировать pg_dump заменив оператор выгрузки COPY на бинарный. В инете есть инфа, что люди так делали, и что характерно, выгруженные данные с исправленного pg_dump`а нормально восстанавливаются стандартным pg_restore.
3. Сами разработчики PG ограничение в 1Гб снимать не торопятся, так как не уверены, что снятие ограничения не вызовет других конфликтов. Вопрос находится в категории «пожелания».

PS: В техподдержку 1С заява отправлеа. ИМХО 1С должна была учитывать эту особенность и хранить конфигурацию как-то иначе.

(120) Снимаю шляпу

(120) фишка заключается в одной маленькой подробности и я об этой подробности выше упоминал уже неоднократно.

А подробность эта свидетельствует о том, что ничего особенного 1С делать не будет. И проблема эта им в 1С известна уже не первый и не второй год.

Вот эта подробность: Особенность в работе с СУБД Postgres наблюдается только с двумя конфигурациями, хотя и в остальных конфигурациях размер превышает в сумме 1Гб - это только КА 1.1 и УПП 1.3

Так что на Ваше ИМХО отвечу своим ИМХО - 1С предлагает просто переходить с КА 1.1 на КА 2.4 без доплаты за апдейт, так же как на любых других ЗУП или БП или УТ
Ну нет официального заявления о прекращении поддержки и какие-то обновления по КА 1.1 выходят, но на системном уровне обеспечить в конфигурации (в ее системно закрытой части) решение такого рода проблемы 1С не станет.

Да и вообще, если смотреть серьезно, то и сама описываемая проблема не является какой-то мега-супер-пупер критичной траблой, а вполне себе обходится на практике ловкостью рук безо всякого мошенничества (и выше об этом в постах тоже было написано) - базу на СУБД можно хранить в виде "снята с поддержки", чтоб конфигурации поставщика в ней просто не было. Ну не нужна там на сервере никому в процессе ежедневной пользовательской работы.

(120) На данный момент проблему резервных копий решили так (в том числе благодаря информации с данного обсуждения) (linux).
Резервная копия создается тремя командами вместо одной:
pg_dump -Z 9 -T config -f путь_к_файлу имя_базы
pg_dump -t config -s -f путь_к_файлу_схемы имя_базы
psql -d имя_базы -c "COPY public.config TO 'путь_к_файлу_конф' WITH BINARY;"

Первой командой выгружаем дамп базы за исключением проблемной таблицы config.
Второй командой выгружаем схему для таблицы config.
Третьей - выгружаем таблицу config в бинарном виде.
В результате у нас на выходе три файла.

Восстановление.
Распаковыввем основной архив:
gunzip --keep путь_к_файлу
Восстанавливаем БД, при этом восстанавливается БД без таблицы config
>psql имя_базы < путь_к_распакованному_файлу
Теперь восстанавливаем таблицу config.
Создаем в БД таблицу config:
>psql имя_базы < путь_к_файлу_схемы
Заливаем в таблицу config данные из файла
psql -d имя_базы -c "COPY public.config FROM 'путь_к_файлу_конф' WITH BINARY;"

(120) Исправлена ли эта проблема в PG 11, которая вышла недавно?

Зачем вам в рабочей базе нужна конфигурация поставщика?

PS: особо всё внимательно не читал, поэтому sorry если уже спрашивали.

PSS: проблемы, возникающие с конфигурацией УПП,  не только связаны с самой конфигурацией, но с "низким" режимом совместимости на "высоких" платформах.

(127) конечно. Поэтому я даже не знаю, как можно рассчитывать на решение подобного рода проблем в конфиге КА 1.1 и УПП 1.3

Если повышение релиза СУБД даст какой-то заметный эффект только при повышении релиза платформы, а релиз платформы упирается в грабли под названием "режим совместимости"

(0) похоже скоро слон будет без альтернатив http://www.cnews.ru/news/top/2018-11-20_microsoft_sokrashchaet_shtat_v_rossii_sotrudnikov

(128) Когда снимут с поддержки и КА 1.1 и УПП 1.3, и у людей не останется выбора, кроме как переползти на КА 2 и ERP, проблема решится сама собой. Наверное, перейти на новые конфы с "переписанных вдоль и поперек" старых будет весьма непросто...

(124) Проверено, работает! Спасибо, жму руку!

Вопрос, а имеет ли смысл каждый раз сохранять таблицу 'config', или ее копию можно делать только после внесений изменений в конфигурацию?

(124)(131) Вот она сила Мисты! Первые подобные проблемы в интернете встечаются очень давно. Но разобрались только в Мисте.

(124) Нужно только не забывать что команда
psql -d имя_базы -c "COPY public.config TO 'путь_к_файлу_конф' WITH BINARY;" - платформо-зависимая.
Может не восстановиться на других релизах и даже при перепрыгивании с х32 на х64.

(133) Думаю никому не придет в голову делать переход на другую платформу через SQL backup/restore. Для таких вещей используют средства самой 1С.

(134) в обсуждаемой ситуации выгрузка в dt проходит без проблем, а загрузка вылетает с ошибкой.
См (75)

(134) я имею в виду релиз PostgreSQL.
Когда я менял релиз постгреса - я делал выгрузку/загрузку dt для 1С-овских баз и dump/restore для не 1С-совских.

Если мне не изменяет моя память, то при переходе с релиза на релиз постгреса, например с 8.4 на 9.1, нужно подключится к серверу постгреса 8.4 утилитой pg_dump из 9.1, сделать бекап и восстановить его в 9.1.
Если я что-то путаю или отстал от жизни - поправьте, пожалуйста.

Соответственно в случае краха сервера (пожар/землетрясение/метеорит) бекапы нужно восстанавливать на том же релизе постреса с той же разрядностью.

(135) Не факт.
Была проблема, что конфигурация из .dt`шника не загружалась. Причина была в том, что на виртуалке с PGSQL было всего 1Гб ОЗУ. Увеличил до 2Гб - все загрузилось. Речь идет о базе как раз подпадающую под обсуждаемую ситуацию.

(135)Потому что при загрузке из dt сервер приложений 1C пишет в базу данных при помощи COPY.
При выгрузке в dt сервер приложений получает данные из СУБД посредством через курсор FETCH, видимо там другой алгоритм выделения памяти, который не приводит к такой ошибке.
Посмотрел сейчас лог PostgrSQL - при выгрузке в dt создается declare cursor mycursor binary специально для таблицы config, и потом fetch.

+(130) Собственно, выбора уже нет - http://catalog.mista.ru/journal/news/mir-1s/polzovateli-1s-kompleksnaya-avtomatizatsiya-1-1-ne-smogut-sdat-otchetnost-za-2019-god_955646/

Жесть какая. Давно я оленей не кормил.
Оказывается в марте уже объявили.

Вопрос к франчам : сколько будет стоить апгрейд с КА 1.1 на УПП 1.3 ?

(141) а могет быть такой апгрейд? Разные продукты вроде как совсем. Да и УПП уже просто так не купить, нужно долго доказывать что она тебе нужна. Апгрейд только на КА2...

(142) для КА 1.1 есть халявный апгрейд на КА 2.4

А вообще, могут зачесть стоимость, как это всегда бывает при смены конфигурации на более дорогую.

(143) на КА2 понятно что есть в том или ином виде. Человек же на УПП хочет :)

Здравствуйте!

(124) А как решили проблему (если решили) с индексацией?

Спасибо.

(146) если схема по команде №2 выгружается с командами создания индексов, то проблемы как будто и нет...

(146) насколько я помню, в полной выгрузке таблица config не упоминается в создании индексов. Т.е. проблем быть не должно.