#SQL Когда фоновый процесс обновления статистики может стать виновником блокировок и чт... — 16 марта 2026 г. в 08:31:37.658
#SQL Когда фоновый процесс обновления статистики может стать виновником блокировок и что с этим можно сделать? Не смотря на то что в целом Автовакуум это неблокирующая операция, всё таки есть возможность получить таймаут на блокировке... Тонкость состоит в том что автовакуум, даже когда он пришёл только лишь обновить статистику накладывает блокировку на схему БД. Т.е. нельзя во время работы автовакуума с таблицей менять в ней состав колонок или удалять таблицу целиком. И тут нам в мире 1С очень "повезло" так как это же операции реструктуризации как версии 1 так и версии 2. В итоге мы при реструктуризации можем получить очень неприятную ситуацию: 1. Автовакуум (автообновление статистики) на таблице занимает более 20 сек 2. Реструктуризация как раз касается этой самой таблицы 3. Через 20 сек после попытки начала реструктуризации этой таблицы получаем ошибку таймаута блокировки и реструктуризация прерывается. Что делать? Если у вас планируется реструктуризация большой таблицы. а обновление статистики более 20 сек может быть только на очень приличной по объёму и количеству строк таблицы, то есть 2 варианта: 1. Отключить на время реструктуризации автовакуум на сервере: ALTER SYSTEM SET autovacuum = off; select pg_reload_conf(); после реструктуризации включить обратно: ALTER SYSTEM SET autovacuum = on; select pg_reload_conf(); либо, если по умолчанию автовакуум включен был, то ALTER SYSTEM RESET autovacuum; select pg_reload_conf(); 2. Отключить автовакуум на конкретной таблице (_inforg38) на время реструктуризации ALTER TABLE IF EXISTS public._inforg38 SET ( autovacuum_enabled = false); select pg_reload_conf(); после реструктуризации включить обратно: ALTER TABLE IF EXISTS public._inforg38 SET ( autovacuum_enabled = true); select pg_reload_conf(); Хочется назвать это костылём, но большие таблицы/базы не живут без таких оптимизаций 😄