Что делать?
Обновили голову до 8.3.18.1208. Сначала было всё хорошо. А вот уже последний месяц - вот такое:

< 2021-03-24 05:23:23.266 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt12')
< 2021-03-24 05:23:23.267 EDT >LOG:  fast-truncating relation pg_temp.tt11
< 2021-03-24 05:23:23.267 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt11')
< 2021-03-24 05:23:23.268 EDT >LOG:  fast-truncating relation pg_temp.tt10
< 2021-03-24 05:23:23.268 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt10')
< 2021-03-24 05:23:24.668 EDT >LOG:  fast-truncating relation pg_temp.tt1
< 2021-03-24 05:23:24.668 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt1')
< 2021-03-24 05:23:34.291 EDT >LOG:  fast-truncating relation pg_temp.tt246
< 2021-03-24 05:23:34.291 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt246')
< 2021-03-24 05:23:34.326 EDT >LOG:  fast-truncating relation pg_temp.tt245
< 2021-03-24 05:23:34.326 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt245')
< 2021-03-24 05:23:34.328 EDT >LOG:  fast-truncating relation pg_temp.tt247
< 2021-03-24 05:23:34.328 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt247')
< 2021-03-24 05:23:34.330 EDT >LOG:  fast-truncating relation pg_temp.tt232
< 2021-03-24 05:23:34.330 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt232')
< 2021-03-24 05:23:34.332 EDT >LOG:  fast-truncating relation pg_temp.tt248
< 2021-03-24 05:23:34.332 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt248')
< 2021-03-24 05:23:34.334 EDT >LOG:  fast-truncating relation pg_temp.tt249
< 2021-03-24 05:23:34.334 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt249')
< 2021-03-24 05:23:34.447 EDT >LOG:  fast-truncating relation pg_temp.tt250
< 2021-03-24 05:23:34.447 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt250')
< 2021-03-24 05:23:34.448 EDT >LOG:  fast-truncating relation pg_temp.tt251
< 2021-03-24 05:23:34.448 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt251')
< 2021-03-24 05:23:34.449 EDT >LOG:  fast-truncating relation pg_temp.tt252
< 2021-03-24 05:23:34.449 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt252')
< 2021-03-24 05:23:34.449 EDT >LOG:  fast-truncating relation pg_temp.tt253
< 2021-03-24 05:23:34.449 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt253')
< 2021-03-24 05:23:37.132 EDT >LOG:  fast-truncating relation pg_temp.tt49
< 2021-03-24 05:23:37.132 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt49')
< 2021-03-24 05:23:42.275 EDT >LOG:  fast-truncating relation pg_temp.tt244
< 2021-03-24 05:23:42.275 EDT >STATEMENT:  SELECT FASTTRUNCATE ('pg_temp.tt244')

Просто очень много в лог идёт. Это что-то сломано или как? Или можно просто отключить логирование этой проблемы?

Вбей в поиск 8.3.18.1208

(0) место на иске быстро заканчивается или в чём проблема?
Не слишком агрессивно автовакуум настроен?

или кто-то шринкует временную таблицу (подозреваю что платформа)

Сервер 1С 32 bit?

Модуль fasttrun предоставляет транзакционно-небезопасную функцию для усечения временных таблиц, предотвращающую разрастание каталога pg_class.

https://postgrespro.ru/docs/postgrespro/9.6/fasttrun

dmrjan нет, 1C сервер x86_64. Версия PostgreSQL: 96-9.6.7-1.1C. Да я читал про этот модуль fasttrun (да, там всё красиво написано, но можно как-то без него?)
rphosts да, очень агрессивно, напрягает, диски изнашиваются, процессор напрягается... Может можно обойтись без этого адского логгирования? Или вообще отключить этот fasttrun и всё будет работать? Тогда как?
piter3 а это мысль... Пойду смотреть release notes...

на 12 посгре переходите

Здесь тоже жалуются - https://www.linux.org.ru/forum/admin/15400910

И уйти с 1208 на последние.

Если log_statement установить в none, то эти сообщения записываться в лог не будут. Впрочем, и другие тоже.
А fasttrun выключить проблематично, его специально для 1С писали, без него работать не будет.
Можно написать в 1С, чтобы они там пореже запускали его, так и сказать - диск изнашивается.

Снизил уровень логгирования до ошибок в postgresql.conf:
client_min_messages = error
log_min_messages = error

Это решило проблему спама в лог! Но... а как же таблицы pg_temp - они создаются на диске или в оперативной памяти? Стоит о них переживать? Может что-то надо делать в конфигурации 1С (УТ11)?

Соврал, опять полезло...

Буду делать раздел в оперативной памяти под эту пертрушку...

(11) тебе надо повысить релиз постгри. Платформа не рассчитывалась на то, чтоб использовался постгри давних релизов.

ansh15 log_statement = 'none' там в конфиге так и есть! А statementы есть всё равно.

@Френки вот 100%, да?

Пока меня спасёт tmpfs, а там посмотрим ^__^

(11) Временные таблицы (если это они) создаются и удаляются практически в каждом нетривиальном запросе в типовых. Это норма. (C)

(16) Прямого указания на то, что 8.3.18 тестировалась с PostgreSQL ниже 12-й редакции и дало 100% правильные результаты, обнаружить не удавалось.
1С пишет, что "Поддержка этой версии в 1С:Предприятии 8.3 реализована в версии 8.3.18 и старше.
Нагрузочное тестирование проводилось на версиях 1С:Предприятия 8.3.18". Интерпретация смысла этого сообщения может быть для разных людей различной. Лично я считаю, что для 8.3.18 лучше использовать 12.5-12.6.

А буквы EDT в логе — это то, о чем я думаю, или что-то другое?

(20) Не думай о нехорошем )