vyegorovНовиков Сергей,

Если написать DO блок и руками по PK пройти по всем записям с изначальным запросом, ловя ошибки, то можно узнать ID записей с кривыми данными.
Затем можно будет эти записи в файл сдампить через COPY (SELECT …) TO и анализировать.
Скажем, написать в 1С и спросить какого лешего почему так получается?..

не получится COPY (SELECT …) TO...
именно из-за
select filename, datasize, length(binarydata::text) from public.config order by datasize;

ERROR: invalid memory alloc request size 1758260518
********** Ошибка **********

там bytea не может в текст превратиться нормально потому что text Больше гига выходит...

кстаааати.... а не поможет ли установка bytea_output в hex вместо escape?
При везении получится меньше гигабайта для текста (раза в 3).


попробуйте сделать

set bytea_output to hex;
select filename, datasize, length(binarydata::text) from public.config order by datasize DESC LIMIT 5;

PS: И покажите если отработает результат все таки (интересно же).

PPS: если поможет то в конфиге пропишите уже bytea_output и попробуйте pg_dump сделать.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru [/quot]

qwwqvyegorovНовиков Сергей,

Если написать DO блок и руками по PK пройти по всем записям с изначальным запросом, ловя ошибки, то можно узнать ID записей с кривыми данными.
Затем можно будет эти записи в файл сдампить через COPY (SELECT …) TO и анализировать.
Скажем, написать в 1С и спросить какого лешего почему так получается?..

не нада всего этого.
там табличка с 1 (одной) записью. в поле байтеа которой лежит одним куском весь т.н. "код 1С конфигурации". т.е. попросту 1 файл. и он превысил спеку на тосты поля пж. (обычно после редактирования "конфигурации" его раздувает.) вот и всё.

выход -- поменять поле на ЛО. но код "1С платформы" будет вероятно хотеть байтеа -- надо проверить.

Там уже последнее время не одна запись а
авторЗапрос выполнен успешно. Общее время выполнения: 233 msec. обработано строк: 33681.
:(
что там в такой ситуации на полгига всунули что оно в escape формате в гиг не влезает - я не понимаю.
Но сильно постарались.
Там кажется bytea который сам по себе в toast влезает а вот в escape output - не влезает уже в лимиты text.
(может помочь смена вывода на hex Тогда МОЖЕТ начнет влезать... 1С то его как то читает... наверное как раз через hex output).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru [/quot]

Новиков Сергей,

А что вообще показывает

select filename, datasize from public.config order by datasize DESC LIMIT 5;

?

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru [/quot]

Новиков СергейПрикладываю результат

Ну вот дальше идете с этим в ОФИЦИАЛЬНУЮ поддержку 1С, показываете 600MB файл в конфиге 1С, объясняете проблему и спрашиваете что делать (и как этот файл правильно удалить).

Т.е. проблема тут не Postgresql а 1С ная... нельзя файлы по полгигабайта грузить туда в той структуре данных что используется 1С.

А что это за файл такой и зачем - это не зная потрохов 1С - я вам не скажу.
Может нужный, может нет.


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru [/quot]

Новиков Сергей,

Вот вам разбор вашей же ситуации.
https://www.postgresql.org/message-id/flat/5519E025.3030704@BlueTreble.com#4a6bbe32b2957650613d5e49c74b407b
Там много интересных замечаний.

Единственный совет - не делайте так (и большие вопросы к авторам конфигурации которые такого монстра сделали).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru [/quot]

Новиков СергейПрикладываю результат

Как быстрое решение - использовать base backup для backup а не pg_dump.
У него таких проблем нет да и быстрее он будет сильно скорее всего.
(но проверить процедуры восстановления обязательно).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru