Те писать ТЖ по дедлокам смысла нет?

Скрин или текст ошибки есть?

в ТЖ пишутся дедлоки от менеджера блокировок 1с, а не от постгреса

Конечно есть смысл, т.к. там будет информация, кто и кого блокирует, т.е. можно понять по контектсу, где кривой код в вашей конфигурации. По сути в 1с два основных вида дедлока, повышение уровня блокировки(поставили разделямую - повысили до исключительной, т.е. читаем-пишем) и второй в виде неправильного порядка захвата ресурса(заблокировали ресурс1 и хотим заблокировать ресурс 2, а второй транзакцией заблокировали ресурс 2 и хотим заблокировать ресурс 1). Если вы ловите дедлок на уровне СУБД пройдя 1с-ый менеджер блокировок, то 1с предлагает считать это ошибкой платформы и просит сообщать о таких ситуациях в поддержку.

Отмечали выше, что Postgres-версионник - не устанавливает разделяемых блокировок, поэтому взаимоблокировок из-за повышения уровня блокировки быть не может...

Все верно, вы абсолютно правы, не стал акцентировать на этом, т.к. с МС мы в большинстве случаев тоже работаем. Основной посыл был, что дедлок на СУБД ситуация ненормальная в случае 1с.

Илья Похожаев
вот такого плана обычно

Первая розница наверное не очень оптимизирована для PG.

да не, для ms sql дедлоки на субд даже в режиме RCSI - частая беда. а вот с пг - это прям редкость и явная ошибка

Какая же разница ms sql RCSI и PG с точки зрения блокировок? В обоих случая не будет разделяемых блокировок... А вместо исключительных сработают блокировки упр - так как они практически всегда устаналвиваются при изменении

MS SQL любит ставить Range-U блокировки по поводу и без повода при записи :) некорректный порядок установки блокировок по несовпадающим измерениям может проскочить менеджер блокировок 1С, но встрять на повышении с U до X на рэнжах

а это разве не разделяемая блокировка ?

Это ShareLock не на строку, а на transactionid и пытается установиться при попытке изменения строки (UPDATE)