Есть 2 базы. БУХ 3.0 и УПП 1.3
Перенос проводил через выгрузку загрузку .DT с предварительным .
Бух 3.0 нормально перенеслась из MS SQL в . Бэкапится и работает.
УПП 1.3: При проведении документа ОШИБКА СУБД cache lookup failed for function 0
привели к необходимости сделать Дамп/Бэкап
При попытке сделать Бэкап, ошибка:
pg_dump: saving standard_conforming_strings = off
pg_dump: saving search_path =
pg_dump: saving database definition
pg_dump: [archiver (db)] query failed: ERROR: invalid memory alloc request size 1191164729
pg_dump: [archiver (db)] query was: FETCH 100 FROM _pg_dump_cursor
Перенос проводил через выгрузку загрузку .DT с предварительным .
Бух 3.0 нормально перенеслась из MS SQL в . Бэкапится и работает.
УПП 1.3: При проведении документа ОШИБКА СУБД cache lookup failed for function 0
привели к необходимости сделать Дамп/Бэкап
При попытке сделать Бэкап, ошибка:
pg_dump: saving standard_conforming_strings = off
pg_dump: saving search_path =
pg_dump: saving database definition
pg_dump: [archiver (db)] query failed: ERROR: invalid memory alloc request size 1191164729
pg_dump: [archiver (db)] query was: FETCH 100 FROM _pg_dump_cursor
По теме из базы знаний
- Скорость работы 1С: Предприятие с разными СУБД: MS SQL и с PostgreSQL
- Собираем образ виртуальной машины с PostgreSQL и платформой 1С. Цикл "Многопоточный CI для 1С c Packer, Vagrant и Jenkins", часть 2
- Интеграция 1С 8.3 с Power BI (Генератор представлений (View) в MS SQL/PostgreSQL по структуре базы данных 1С 8.3)
- Скрипты MS SQL, Postgres, cmd, power shell WMI
- Инструкция по бэкапу одной базы в Postgres – миф или реальность
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)Откуда брали сборку postgresql?
ERROR: invalid memory alloc request size 1191164729 - в одной ячейке записано более 1ГБ данных, pg_dump не умеет с этим работать, так как справедливо считает что такое хранить в БД нельзя. Скорее всего это таблица config, здесь где была статья как это обойти.
ERROR: invalid memory alloc request size 1191164729 - в одной ячейке записано более 1ГБ данных, pg_dump не умеет с этим работать, так как справедливо считает что такое хранить в БД нельзя. Скорее всего это таблица config, здесь где была статья как это обойти.
(1)
Доброго дня.
Аналогично пытался перенести упп на postgres. База около 30 гиг размером.
PG с сайта 1с последний. Предприятие оттуда же, 8.3.15....
Получил такую же ошибку.
Дамп делал, не помогло.
Так же пробовал делать тестирование и исправление. Все проходит успешно, если не ставить галку "реструктуризация таблиц". На этом падает.
Но эффект от этих действий нулевой.
Пришлось вернуться к mssql.
Осталось попробовать только pg_dumpall.
Доброго дня.
Аналогично пытался перенести упп на postgres. База около 30 гиг размером.
PG с сайта 1с последний. Предприятие оттуда же, 8.3.15....
Получил такую же ошибку.
Дамп делал, не помогло.
Так же пробовал делать тестирование и исправление. Все проходит успешно, если не ставить галку "реструктуризация таблиц". На этом падает.
Но эффект от этих действий нулевой.
Пришлось вернуться к mssql.
Осталось попробовать только pg_dumpall.
Тоже перенес на Postgres
8.3.16.1148 конфиг бухгалтерия 1.2
база маленькая, места навалом, проверка и рестурктуризация на ура
А вот отмена проведения произвольного документа (не всех) вываливает эту ошибку
Нагуглил что это связано с шаманствами преобразования строк mvarchar - но как исправить не нашел
8.3.16.1148 конфиг бухгалтерия 1.2
база маленькая, места навалом, проверка и рестурктуризация на ура
А вот отмена проведения произвольного документа (не всех) вываливает эту ошибку
Нагуглил что это связано с шаманствами преобразования строк mvarchar - но как исправить не нашел
Бухгалтерия 2.0
Очередное обновление потребовало обновление платформы. Заодно, решили обновить PostgreSQL.
И так, платформа 8.3.16.1148 и PostgreSQL 11.5-12
В итоге, на многих операциях (проведение документа, пометка на удаление и тп) - ОШИБКА СУБД cache lookup failed for function 0
Пришлось понизить версию PostgreSQL до 10.10-4
Очередное обновление потребовало обновление платформы. Заодно, решили обновить PostgreSQL.
И так, платформа 8.3.16.1148 и PostgreSQL 11.5-12
В итоге, на многих операциях (проведение документа, пометка на удаление и тп) - ОШИБКА СУБД cache lookup failed for function 0
Пришлось понизить версию PostgreSQL до 10.10-4
словил такую ошибку при распроведении/проведении документов после обновления постгре с 11.5-7.1C на 11.5-12.1C на базе БП 2.0. Шаманства с загрузкой/выгрузкой/восстановлением не помогли. В файловом варианте все работает. Пришлось откатиться на 11.5-7.1C
Поимел такую же ошибку (ОШИБКА СУБД cache lookup failed for function 0) на УПП 1.3, релиз 1.3.134.1, платформа 8.3.15.1489, постгрес 11.5-12.1С(х64).
База небольшая, dt 1.3гб. *.dt выгружается, на файловой базе ошибки нет. Конфигурация почти типовая, но без замочка.
Использовал различные танцы с бубном навроде: майнтенанс базы pgAdmin-ом, ТИИ, вкуривание логов постгре, изменение регистра бухгалтерии туда-сюда (для инициирования реструктуризации и пересоздания таблиц в постгре), удаления проблемной таблицы средствами постгре. Логи постгре говорят, что проблема в таблице итогов регистра бухгалтерии по субконто _AccRgAT21653. Но что с этой таблицей ни делай, ошибка возвращается.
РЕШЕНИЕ:
поставил в конфигурации режим совместимости "Версия 8.3.9". Да, появляются артефакты, вроде дублирования имен картинок (которые в 8.3.9 стали системными) и некоторых функций общего модуля ОбщийМодуль.ИнтеграцияЕГАИСУТКлиентСерверГлобальный.Модуль(8,9)}: Процедура или функция с указанным именем уже определена (СтрНайти) - нужно переименовывать функции.
Но проблема с cache lookup failed ушла. Прогонял разные документы - пока все ровно. Буду наблюдать далее.
BTW: УПП в дефолтовом режиме совместимости весьма плохо дружит с постгре в плане производительности. на большой базе с количеством пользователей около 100 было невозможно работать, пока не поднял режим совместимости. После этого платформа 1с начинает генерировать адекватные запросы в постгре.
Спасибо за внимание.
База небольшая, dt 1.3гб. *.dt выгружается, на файловой базе ошибки нет. Конфигурация почти типовая, но без замочка.
Использовал различные танцы с бубном навроде: майнтенанс базы pgAdmin-ом, ТИИ, вкуривание логов постгре, изменение регистра бухгалтерии туда-сюда (для инициирования реструктуризации и пересоздания таблиц в постгре), удаления проблемной таблицы средствами постгре. Логи постгре говорят, что проблема в таблице итогов регистра бухгалтерии по субконто _AccRgAT21653. Но что с этой таблицей ни делай, ошибка возвращается.
РЕШЕНИЕ:
поставил в конфигурации режим совместимости "Версия 8.3.9". Да, появляются артефакты, вроде дублирования имен картинок (которые в 8.3.9 стали системными) и некоторых функций общего модуля ОбщийМодуль.ИнтеграцияЕГАИСУТКлиентСерверГлобальный.Модуль(8,9)}: Процедура или функция с указанным именем уже определена (СтрНайти) - нужно переименовывать функции.
Но проблема с cache lookup failed ушла. Прогонял разные документы - пока все ровно. Буду наблюдать далее.
BTW: УПП в дефолтовом режиме совместимости весьма плохо дружит с постгре в плане производительности. на большой базе с количеством пользователей около 100 было невозможно работать, пока не поднял режим совместимости. После этого платформа 1с начинает генерировать адекватные запросы в постгре.
Спасибо за внимание.
Возникла такая же ошибка. Сделал как советовали. Все получилось как в описании. Правда функций переименовать пришлось 6 штук. И вопрос возник: как то влияют не уникальные имена картинок на работу системы? Конфигурация Комплексная автоматизация торговли алкогольной продукцией 1.1.115.1 (поставщик ООО "Компьютерные технологии 2000")
То же поймали ошибку ОШИБКА СУБД: XX000: ERROR: cache lookup failed for function 0, когда обновили полностью платформу (с 8.3.16.1063 на 8.3.17.1549) и постгрю с 9.4.10 (postgrespro) на 11.7_7.1C (от 1с).
Причем ЗУП 3 и УПП 1.3.106.2 работают нормально, а Бухгалтерия 2.0.66.117 выдает ошибки при проведении документов "Отчет производства за смену" при попытке смены склада либо замены номенклатуры на вкладке Материалы, и проведении банковских выписок. Больше не пробовали, надо работать, откатили постгрю назад - все нормально.
Решили проверить работу на сборках PostgresPro:
- на PostgreSQL_1C_11.8 - ошибок нет!
- на PostgreSQL_1C_12.3 - ошибок снова нет! И работает быстрее.
Заливали базы через dt.
Проблема как видите решается гораздо проще!
Ведем переписку с ТП от 1с, кинули им ТЖ, пока ничего вразумительного, но 1с-ные недосборки постгреса уже идут лесом навсегда.
Причем ЗУП 3 и УПП 1.3.106.2 работают нормально, а Бухгалтерия 2.0.66.117 выдает ошибки при проведении документов "Отчет производства за смену" при попытке смены склада либо замены номенклатуры на вкладке Материалы, и проведении банковских выписок. Больше не пробовали, надо работать, откатили постгрю назад - все нормально.
Решили проверить работу на сборках PostgresPro:
- на PostgreSQL_1C_11.8 - ошибок нет!
- на PostgreSQL_1C_12.3 - ошибок снова нет! И работает быстрее.
Заливали базы через dt.
Проблема как видите решается гораздо проще!
Ведем переписку с ТП от 1с, кинули им ТЖ, пока ничего вразумительного, но 1с-ные недосборки постгреса уже идут лесом навсегда.
На УПП 1.3 падало с ошибкой. Обновил Постгрес с 12.4 на 12.5 (1с-сборка) - ошибка осталась. Поставил 12.5 от постгрес про - завелась сразу и ошибка пропала. В общем на будущее - лучше сразу постгрес про сборку ставить :)
эту ошибку, еще в декабре, но с исправлением пока туго.
Так как сообщения об ошибке возникают, в основном, на конфигурациях "старой закалки", процесс исправления, возможно, будет и не таким уж быстрым(если вообще будет)...
Планируется исправление в будущих версиях
Так как сообщения об ошибке возникают, в основном, на конфигурациях "старой закалки", процесс исправления, возможно, будет и не таким уж быстрым(если вообще будет)...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот