Всем привет ! Есть база 1С на постгри. Делаю бэкап. Бэкап проходит с предупреждениями

pg_dump: [sorter] ПРЕДУПРЕЖДЕНИЕ: не удалось разрешить цикл зависимостей для следующих объектов:
pg_dump: [sorter]   DUMMY TYPE __document70_vt161_intkeyind  (ID 1208 OID 278566)
pg_dump: [sorter]   DUMMY TYPE _document70_vt161_intkeyind  (ID 2976 OID 278567)
pg_dump: [sorter]   INDEX _document70_vt161_intkeyind  (ID 8410 OID 278565)
pg_dump: [sorter]   POST-DATA BOUNDARY  (ID 9300)
pg_dump: [sorter]   TABLE DATA config  (ID 8929 OID 258801)
pg_dump: [sorter]   PRE-DATA BOUNDARY  (ID 9299)


Что н так ?

Кто ж знает

Жаловались, не так давно https://www.linux.org.ru/forum/admin/14704848
Сам тоже такое видел. Получилось после того, как сделал vacuum full, а потом сразу выгрузил pg_dump-ом. В новую пустую базу с другим именем загрузилось без ошибок и pg_dump потом тоже ошибок не выдавал. В этой базе, заново созданной с этим же именем, и загруженными данными хоть pg_admin, хоть из *.dt, ошибка возникала.
Поступил согласно совету "Если компьютер работает плохо, переустановите Windows" - удалил кластер PostgreSQL, инициализировал заново, залил базу из .dt. Больше такая ошибка не возникала. Что там было - непонятно.

Да что то  такое есть. Если создать новую базу и поднять с бэкапа там и его же бэкапить, то ошибок нет. По ходу pg_dump  убирает несогласованные вещий.

Лучше бы 1с поддерживала fb/ib вместо постгреса..)

(4) и чем интербэйс был бы лучше?

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

Но вообще, гипотетически допускаю, что кроме уже существующих форматов баз могут в новых релизах вывести еще что-то.
Например, и вовсе свой собственный файловый режим довести до нормальной многопользовательской работы.

(4) fb/ib еще и не рассчитаны на базы приличных размеров. По крайней мере так было.

(8) Да нет, всё нормально они рассчитаны. У них проблема действительно в том что могут затупить на сборке мусора. Но вакуум в постгресе - примерно та же фигня.

+(9) Зато бэкапить и восстанавливать одно удовольствие, никаких "кластеров": одна база - один файл.

+(2) В общем, это не из-за vacuum. Ситуация возникает после реструктуризации таблиц в ТиИ. После нее pg_dump начинает выдавать такие предупреждения. И похоже, такое происходит в версии платформы 8.3.14. Ни в версии 8.3.15, ни в более ранних(< 8.3.14) этой ситуации не наблюдается.

(2) не могло помимо создания бэкапа чего-то в базе изменяться сеансами пользователей/регламентными?

(4) у нас на fb база проходной перко (одна на все филиалы)... раз в год ей устраивают обрезание ибо не тянет ни в какую...
Fb на что-то серьёзное ставить - получать кучу проблем на пустом месте

(12) Нет, специально эксперимент проводил, на копии. Ни пользователей, ни регламентных, все выключено. После реструктуризации останавливал сервер приложений, чтобы ничего не мешало. До нее сообщений не возникало.