Доброго времени суток! Хотя у кого доброе, у кого не очень.
У клиента упала база. Получилось так, что кривой админ настроил бэкапы на тот же диск с базами, бекапы забили весь диск. Я стал накатывать изменения, место кончилось, 1с вылетела. Теперь в конфигуратор не заходит, ошибка:
Попытка получения не инициализированного параметра сеанса.

В обычном режиме тоже не заходит, ошибка:
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call/cb747d24-6d8a-4d97-8a13-305ee6f39f75/d5963243-262e-4398-b4d7-fb16d06484f6:
по причине:
Ошибка SDBL:
Таблица CommonSettings не имеет нового поколения и не может быть модифицирована

Что пробовал: копировать таблицы config, configsave из тестовой базы, там разница в конфе в пару реквизитом. Не помогло :(
Бекапы 3-х недельной давности, т.к. места не хватало под бэкапы давно, а база растет не быстро.
Что еще можно попробовать для восстановления базы?

Пулю в колено сисадмина. Предлагаю взбодрить его хорошенько.

перед танцами с бубном сделать бэкап
вторым пунктом почистить кеш

для начала запустить базу pgsql с LC_MESSAGES=en_US.UTF-8, т.к. сообщение про новое поколение не вяжется со здравым смыслом

либо можно поискать в исходниках этот кривой перевод, найти соответствующее сообщение на английском и понять о чем оно


я LC_MESSAGES всегда выставляют при initdb, на уже созданной базе как-то не приходилось менять

затем в postgresql.conf выставить параметр log_statement в ddl или all и пытаться найти, какой именно запрос обваливается среди мегабайтов лога

1) ...кривой админ настроил бэкапы на тот же диск с базами...
2) ... Я стал накатывать изменения...

Чего то не хватает меж этими действиями.

(0) А очистить место на сервере пробовал?

место почистил первым делом, вторым кэш, третим сделал бекап битой базы

кто виноват предлагаю не обсуждать. надо попробовать восстановить базу, админу будет урок, да и мне ))
все осложняется, что человек кто ставил скуль недоступен, а я с постгре не работал. В мс скуле попробовал бы что-то сделать.
Да и здесь пробую, но пока безрезультатно

(3) похоже, это не pgsql выдает такое сообщение, а сама 1С

думал ругается на таблицу _commonsettings , очистил ее (бэкап есть), не помогло

(9) кмк поломалась структура в конфигурации посреди обновления, т.е. еще до уровня базы

(10) да мне тоже так показалось. Но почему тогда не помогает копирование конфигурации из тестовой?

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

/me в таких вопросах не силен

возможно, закончится все ручным перенакатом документов за три недели, хренпойми как выдранных из поломанной базы

админу действительно колено прострелить за такую организацию бэкапов

Базу удалось восстановить. Поигрался с таблицами конфы, удалил таблицы dbchanges? dbchangesog и еще какую-то.

ну и про судьбу админа расскажи )

Надеюсь, теперь бэкапы делаются на другой диск.
(14)ИМХО. Его не было. Был "малчик", который убежал давно после установки.

(15)
> который убежал
у батареи смотрели?)

Админ внештатный, как собственно и я. Что там с ним сделали, не знаю, может у батареи сидит :) Когда им базу восстановил, они, наверное, всем офисом плясали :) Рассказал что бекапить нужно на другой диск или комп. Будут исправлять бекапирование.

(17) Лучше научиться делать бекап перед "накатыванием изменений"