Нетиповая БП 3.0 на PostgreSQl. Добавил вчера вечером 1 реквизит в самописном документе, нажал "Обновить конфигурацию" и база висела 4 часа, делала обновление и реиндексацию. Но ночью сервер 1С автоматически перезагружается и видимо 1С не хватило времени закончить реиндексацию и обновление.
Утром зашел в конфигуратор, "синий цилиндр" активен. Откатился к конфигурации БД и зашел в 1С.
Всё работает, кроме того самописного документа, в котором делались изменения. Если зайти в форму списка этого документа, то 1С просто зависает.

Вопрос: что можно сделать? Можно ли делать reindex средствами postgres на рабочей базе при активных пользователях?

Сталкивался с такой шляпой: на postgres тупо ни в какую не проводился один документ, причем с небольшим количеством строк в ТЧ(хоть 1, хоть 10 000) - результат один - наглухо зависает сеанс. При этом на MSSQL всё нормально работает.

А вот на рабочей базе при активных юзерах ух как не советую запускать регалменты СУБД...

(0) бэкап есть?

(2) Спрашивал бы он, будь у него бэкап

Бэкап есть вчерашний, но за утро уже очень много изменений в базе сделали

(4) а че у пиздгреса нет аналога dbcc checkdb чтобы понять в чем проблема?

ЗЫ чета я сомневаюсь что проблема только в переиндексации, этот пиздгрес такая подлая тварь что не поймешь что ему не нравится, лучше восстанавливайся из бэкапа, а то потом еще годами будешь баги ловить

(4) ну, это же элементарно, ватсон. Ставишь вчерашний бэкап, а потом аккуратненько обработочкой ВыгрузкаЗагрузка xml загружаешь в него всё, что с утра набили.

(6) а если правили прошлые периоды утром, справочники меняли? совет из рубрики "вредные советы"

(7) Пропарсить ЖР.

столько ошибок новичка:
не дождался окончания обновления;
не отключил перегрузку сервера 1С;
после выявления аварийной ситуации разрешил пользователям работать...

(7) это всё решаемо. Даже просто объявить пользователям, что был сбой и чтобы они всё проверили - уже решит 95% вопросов.

(6) документы в базе создаются 24/7 автоматически через веб-сервисы (тысячи за день). Есть большая вероятность, что какие-то документы можно упустить

(0) Поднимаешь базу из архива, сделанного до обновления; выгружаешь конфигурацию; делаешь копию рабочей базы средствами PostgreSQl (не выгрузка/загрузка в *.dt); загружаешь туда ранее выгруженную конфигурацию и вносишь нужное тебе изменение; обновляешь и проверяешь работоспособность копии базы. Если всё "Ок" - ты знаешь что делать дальше.

(11) такой вероятности нет. Просто сравниваете отчетами потом.  Делаете отчет в новой и старой базе, тупо сравниваете.

(не в тему) Чисто теоретически я могу написать обработку в 1С, которая просканирует и сравнит все объекты рабочей базы и базы устаревшего архива, выявляя все изменения... Но  это не наш путь :)

(опять же не в тему) Берём любую базу, где есть РАУЗ и расчет себестоимости, исправляем пару документов "задним числом" в
закрытом периоде, пересчитываем себестоимость... и после этого внимательно слушаем, что скажет четыре буквы "h" про то, как вернуть базу к исходному оригинальному состоянию  :)

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

(11) При таком режиме работы и вносить изменения сразу в рабочую базу... И да как это соотносится с "база висела 4 часа, делала обновление и реиндексацию"

Проблема была в том, что не хватило место на жестком диске из-за того, что Postgres несколько дней назад начал создавать большое количество объёмных временных файлов в папку pgsql_tmp. Из-за этого 1С не смогла закончить реструктуризацию и не открывала самописный документ, таблицы которого изменились и нуждались в реструктуризации.

Решение: удалил временные файлы в папке pgsql_tmp, сделал копию выгрузкой dt, и запустил ТиИ с галочками реиндексация, реструктуризация. После этого база как новая. Работает быстро, все документы открываются без проблем.

P.S. у клиента стояла платформа 8.3.10.2561. По идее с версии 8.3.11.2867 такой проблемы в теории возникнуть не должно, т.к. там реализован новый алгоритм реструктуризации после обновления (https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/)

(17) Ага, а еще для такой нагруженной системы применять бесплатную БД, без хороших знаний по ней - путь к (0).