Обновил платформу до с 8.3.12 на 8.3.13.1644. Заодно обновил posgresql с 9.6 до 10.5. Ожидал волшебного прироста производительности за счет улучшенной совместимости в новых версиях, но нет.

Зато начали в разных местах обваливаться запросы с сообщением:
"variable not found in subplan target lists"

Обваливаются запросы, в которых нагорожен огород типа:
ГДЕ НОЛЬ - ТОГДА НОЛЬ, А ЕСЛИ НЕ НОЛЬ - ТОГДА НОЛЬ ПОМНОЖИТЬ НА СУММУ(случайная колонка)
ОБЪЕДИНИТЬ
ГДЕ НОЛЬ - ТОГДА НОЛЬ, А ЕСЛИ НЕ НОЛЬ - ТОГДА НОЛЬ ПОМНОЖИТЬ НА СУММУ(другая случайная колонка)


(*утрирую)

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

Это 1с 8.3.13 или postgres-10.6?

plantuner пробовал выключать - это не он, проблема не уходит.

(0) Не пишите идиотские запросы. Или переходите на MS SQL.

(1) Я-то красоту распрекрасную пишу, обычно руками без трансляторов и всяких построителей. Таким образом, чтобы запрос выполнялся не более одной секунды.

А вот чего в типовой БП пишут - ну чего пишут, того пишут. Могу только платформу чуть другую поставить.

(0) а если не утрируя сверить с этим, похоже?

Запрос, содержащий ОБЪЕДИНИТЬ
Код ошибки: 10188035
Код(ы) обращения: SW1220805
Статус: Исправлена в тестовой версии Зарегистрирована: 07.12.2017
Исправлена: "Технологическая платформа", версия 8.3.14.1373 (для тестирования)
Описание:
При исполнении запросов, содержащих ОБЪЕДИНИТЬ или ОБЪЕДИНИТЬ ВСЕ, может происходить ошибка с текстом
Ошибка СУБД:
Ошибка SQL: Поле не входит в группу
или подобным, если во втором или последующем запросе используется группировка, и тип столбца результата запроса отличается от типа соответствующего столбца в первом запросе.

(3) не совсем похоже, но пошел обновлять тестовый сетап на 8.3.14

(4) Помогла 14я платформа?

(5) с 14 платформой не так все просто оказалось в плане развернуть бесплатно на тестовом сервере, а вот обновление БП - помогло

В БП 3.0.65.72 с такой ошибкой вываливалась ОСВ (не по счету, а в целом), после обновления до 3.0.67.54 - в этом месте больше не вываливается.

УТ 11.4.6.174 вываливается при открытии документа Задание на перевозку.

Сегодня зарелизилась 8.3.13.1690

(7) чем сильно лучше предыдущей?

(8) да, как обычно - старые ошибки поправили, новых добавили. надо же бизнес на плаву держать ))

Было: платформа 8.3.13.1644, Postgresql 9.4, БП 3.0.67.38
работало.
Обновил postgres до 10.5-9.1C
При формирование ОСВ с первого числа по последнее число любого периода вываливается "variable not found in subplan target lists" .
01.12.2018-31.12.2018 - ошибка
01.12.2018-01.01.2019 - нет ошибки
01.12.2018-30.01.2019 - нет ошибки
Обновил БП до 3.0.67.63 не помогло.

(10) аа, действительно, ничего не починилось.
Подтверждаю про даты.

Обновил до 3.0.67.67 не помогло.
Буду пробовать откатывать версию Postgresql на 10.3-3.1C    от 25.10.18

(12) как вариант можно выбрать один из счетов
вся ОСВ выводится в виде конечной суммы, а конкретный счет - подробно.

Мои бухи говорят - так жить можно, хоть и грустно.

(8) Пару каких-то больных ошибок пофиксили. Все что после 8.3.9.1850 - УГ какое-то.

Тоже вываливается ошибка при формировании ОСВ за 18 год -  Postgre 10.5-9.1C, платформа 8.3.13.1644 конфигурация 1С:Управление микрофинансовой организацией и кредитным потребительским кооперативом КОРП. Кто-то пробовал писать на ЛК 1С? (12) проблема решилась откатом Postgre?

Так же имею:
Postgre 10.5-9.1C, платформа 8.3.13.1644 конфигурация 1С:ERP2
получаю Error: variable not found in subplan target list
не везде.
Как назло у главного бухгалтера
при формировании ОСВ за 18 год с 1.01 по 31.01
Error: variable not found in subplan target list
НО:
у других пользователей такой ошибки нет.
Уровнял в правах пользователей (ну по крайней мере внешне)
пока не помогает.

КЭш на рабочей станции чистил

(16) думаю от прав пользователя это не зависит, видимо проблема в Postgre 10.5-9.1C и платформе...

(16) можт у неё (ГБ) какие-то поля дополнительно в СКД выведены ? попробуй у неё в ОСВ вернуть "Стандартные настройки"...

Да с "простой" стандартной настройкой - ошибка,
со стандартной настройкой "развёрнутое сальдо" - формируется.

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

Обвновление платформы до 8.3.13.1690 не помогает.
Откат версии postgresql до 10.3-3.1C проблему Решает.

Ответ поддержки 1с:
16 Январь 2019 г. (Ср) 17:30
"Ошибка  00112568 воспроизводится, находится на расследовании"

(22) простите за тупой вопрос, но как откатить  postgre до 10.3-3.1C? Какими образом вы это делали? Понятно, что забепкапить базу и инсталировать 10.3-3.1C на сервер, у меня win server 2012

(24) У меня баз не так много и centos 7 не Win.  Удалил полностью 10.5, установил 10.3, пересоздал базы в кластере 1С и залил dt в них. pg_dumpall делал, но не известно, как сработает postgres на заливку pd_dumpall в версию ниже, а делать дампы отдельных баз самим postges лениво.
И я думаю надежней всего родная выгрузка-загрузка dt.

Сегодня вышла версия 10.5-10.1C. С нашей платформой 8.3.13.1644 - ошибка по-прежнему сохраняется (последнюю платформу 8.3.13.1690 не пробовали). PostgreSQL на Windows Server 2008 R2. Откатываемся к 10.3-3.1C, на виртуалке проверили - во всяком случае эта ошибка исчезла.

В оборотке зашел в Настройки - Стандартные настройки - Настройки с развернутым сальдо.  И Все сформировало!!  Платформа 8.3.13.1644  Postgres 10.5-9.1C  Релиз БП 3.0.67.67

Разработчики посоветовали: Можно попробовать следующий обход
>
> в postgresql.conf
>
> выставить
>
> join_collapse_limit = 1

В моём случае помогло.

(28) понизил join_collapse_limit с 20 до 1 - ОСВ в БП начала запускаться, зато установки цен в УТ не открываются (либо открываются бесконечность)

Там еще вроде как перестроение индексов нужно было произвести.
Переход с предыдущих версий на версию 10.5

    Рекомендуется выполнить переиндексацию таблиц базы данных при переходе на версию PostgreSQL 10.5. Переиндексацию можно выполнить двумя способами:
        С помощью механизма тестирования и исправления конфигуратора, указав режим Реиндексация таблиц информационной базы.
        С помощью административных средств СУБД, выполнив команду reindex database <имя-базы-данных>.


Источник: http://downloads.v8.1c.ru/content//AddCompPostgre/10_5_10_1C/postgreUpdate_ru.htm#36e80798-ee32-11e8-a3f7-0050569f678a

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

Кто-нибудь еще использует PostgreSQL 10.5-10.1C? Не выявились ли еще какие-нибудь ошибки?

У нас стоит 10.3-3.1C (УПП+ЗУП 3.1) на Debian. Хотел в выходные обновить, но увидел эту ветку и задумался - надо ли...

Спасибо.

(31) 13 платформу не ставь тока

(32) 13 платформа уже стоит, причем не самая удачная (8.3.13.1513),  но пока вроде критичных для нас ошибок не замечено, поэтому пока останемся на ней.

Поставил, т.к. на момент установки на сайте 1С было написано "Внимание! Текущая версия PostgreSQL предназначена для использования с версией технологической платформы 1С:Предприятие 8 не ниже 8.3.13.1513. "

(30) Лучше бы они предупредили, что изменилась схема хранения конфигурации. Сейчас не упомню, но при подключении к pg-10 платформа возжелала увидеть колонку, которой нет в таблице толи Config то ли Files. Это хорошо у меня базки маленькие - я в dt выгрузил находясь на pg-9, и в новую с нуля загрузил. Так что reindex у меня вышел вынужденный.

А как быть тем, у кого базы огромные и выгрузка в dt падает?

В плане поиска особенностей перехода на более новую версию действительно как-то стало тяжелее искать.

https://postgrespro.ru/docs/postgrespro/10/release-10-5.html

https://postgrespro.ru/docs/postgrespro/10/config-one-c

Если вы ранее использовали pg_repack в системах на базе Debian, при переходе на эту версию вы должны будете переустановить соответствующий пакет вручную, так как он был переименован в pg-repack-std-10.

Для перехода с PostgreSQL или версии Postgres Pro Standard, базирующейся на предыдущем основном выпуске PostgreSQL, обратитесь к инструкциям в Замечаниях к выпуску Postgres Pro Standard 10.1.1. Если вы выбираете вариант с выгрузкой/восстановлением данных, обязательно используйте параметр --add-collprovider, чтобы в восстановленной базе данных оказался корректный провайдер правил сортировки.

PostgreSQL, версия 10.5-11.1C, сегодня выложили.
Посмотрите, может быть исправили.

Изменения только в 00007-remove_selfjoin.patch, и похоже, что по теме:

-+      // !!!FIXME what about placeholders and upper-level tlists (e.g. for grouping)?
-+      // The placeholders apparently work somehow due to the fact that they reference
-+      // the same Var objects that we modify to point to the other relation.
++      /*
++       * Likewise update references in PlaceHolderVar data structures.
++       */

на выходных попробую

(39) "apparently work somehow" бгг, чувствуются наши духовные скрепы

не удержался, обновил.

НЕТ, ОСВ НЕ ПОЧИНИЛИ

31.01 версия 8.3.14.1565 вышла, кто-нибудь пробовал обновлять для решения проблемы?

Около недели как перешли на CentOS 7, Postgres 10, и платформа 8.3.13.1690. И сегодня вечером начала сыпаться эта ошибка при формировании оборотно-сальдовой ведомости.

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

апну

(44) обновил на 8.3.14.1565, к сожалению проблема осталась... Что еще можно попробовать? Обновить Postgresql?

(45) запрос в осв

(46) Учитывая (23), видимо, над этим сейчас и бьются. Почти месяц уже...

(28) Коллеги, помогло решение описанное выше. Как то я пропустил его раньше.

Разработчики посоветовали: Можно попробовать следующий обход
>
> в postgresql.conf
>
> выставить
>
> join_collapse_limit = 1

В моём случае помогло.

(48) +1, заработала ОСВ

(0) На версии 8.3.12 столкнулся с аномалиями в запросах (казалось бы простой запрос, не показывает данные),  а вы тут про оптимизацию размечтались :)

(1) май скуль тоже не гарантирует, 1С обещает :)

https://bugboard.v8.1c.ru/error/000050878.html
Никто еще не сталкивался?

(52) не-не-не с такими приколами подожду годовщины десятки

(52) походу при сборке pg стоит MVARCHAR оставлять, а остальную "оптимизацию" не включать.

особенно когда прямо в исходниках, добавленных фирмой 1С, встречаются комменты "apparently work somehow"

(29) (48) (49) Опытным путем выяснил, что при значении join_collapse_limit = 2 установки цен в УТ все еще открываются, а ОСВ уже работает. При значении 3 и выше - не работают установки цен в УТ, при значении 1 - не работает ОСВ в БП.

PostgreSQL, версия 10.5-24.1C выложили.
Что там исправили/добавили еще не смотрел.

(56) "follow work could be done only in normal processing because of accsess to system catalog"
"isDisable"
"inited"

Мутко наняли штоле? Мне кажется, (54) все актуальнее становится. Раньше этот патч один Сигаев считай тащил, а тут набрали у ларька по объявлению и понеслась.

А вообще много изменений про JOIN-ы, даже тестов добавили, так что надо пробовать.

(57) Ну, у семи нянек...

(57) б, это Сигаев и коммитил. Мне как-то стыдно теперь.

(0) Не знаю, зачем вам так нужна 10 версия постгреса. Я провел тесты и прироста не увидел, а скорее наоборот. Windows 10 (1809), тест гилева: 9.6.5-4.1С – 51.5 балл, 10.5-24.1C – 50 баллов. По тесту фрагстера везде на 200-300 меньше у десятки, только регистр накоплений на 100 больше, тест в 1 поток. УТ 11.4.6.230, попробовал сформировать книгу продаж – десятка на 30% дольше формирует, отчеты по реализованной номенклатуре одинаково. У нас только реализации и номенклатура, нечего особо тестить, но мне и этого хватает. Где там это увеличение производительности – не ясно, по крайней мере под виндой.

(56) с релизом 10.5-24 ОСВ в БП3.0 работает при любом значении join_collapse_limit; установки цен в УТ11 открываются.