При работе с информационными базами 1С на СУБД PostgreSQL пользователи иногда сталкиваются с плавающей ошибкой вида 42P01: ERROR: relation "pg_temp.ttXXX" does not exist. Эта ошибка указывает на то, что запрос пытается обратиться к временной таблице, которая по какой-то причине уже не существует или не была создана в текущей сессии. Мы рассмотрим подробнее причины возникновения этой проблемы и разберем по шагам возможные пути ее решения, основываясь на опыте пользователей и рекомендациях специалистов.
Для начала, давайте выясним, что означает эта ошибка. Временные таблицы (pg_temp.ttXXX) в PostgreSQL — это особые таблицы, которые существуют только в рамках одной пользовательской сессии и автоматически удаляются при ее завершении. Платформа 1С активно использует временные таблицы для построения сложных запросов, агрегации данных, работы с виртуальными таблицами и промежуточных вычислений. Она может создавать и удалять десятки или сотни таких таблиц в течение одной операции.
Когда вы видите ошибку relation "pg_temp.ttXXX" does not exist, это говорит о том, что платформа 1С сформировала запрос, который ссылается на временную таблицу pg_temp.ttXXX, но к моменту выполнения этого запроса СУБД сообщает, что такой таблицы в текущей сессии не существует. Это может происходить по нескольким причинам:
Особенностью, которую отмечают пользователи, является плавающий характер ошибки: один и тот же документ может успешно проводиться в один момент и выдавать ошибку в другой. Часто это связано с количеством последовательно проводимых документов или общей нагрузкой на систему, что указывает на взаимосвязь с ресурсами сервера.
Прежде чем переходить к конкретным решениям, нам необходимо собрать максимум информации о поведении системы. Это поможет точнее определить корень проблемы.
Технологический журнал 1С является бесценным инструментом для диагностики. Мы рекомендуем собрать полный технологический журнал в момент возникновения ошибки. В нем вы сможете увидеть:
Для настройки технологического журнала вам потребуется создать или отредактировать файл logcfg.xml в папке conf кластера серверов 1С и указать необходимые события для записи. Обязательно включите события, связанные с работой с СУБД (например, DBMSSQL, DBPOSTGR, DBORA в зависимости от СУБД) и ошибки платформы.
Логи самой СУБД PostgreSQL также содержат важную информацию. Мы должны внимательно изучить их на предмет ошибок, предупреждений или необычных записей, которые совпадают по времени с возникновением проблемы в 1С. PostgreSQL может записывать информацию о нехватке памяти, проблемах с блокировками, ошибках при создании/удалении временных файлов и т.д. Убедитесь, что уровень логирования PostgreSQL настроен достаточно подробно (например, log_min_duration_statement = 0 для всех запросов или log_error_verbosity = verbose для более детальных сообщений об ошибках). Для перевода SQL-запросов из логов в термины метаданных 1С подойдёт инструмент трансформации запросов СУБД.
Важно постоянно отслеживать использование оперативной памяти, процессора, дисковой подсистемы (особенно для каталогов, где PostgreSQL хранит данные и временные файлы). Инструменты мониторинга (например, perfmon в Windows, htop/top в Linux или специализированные системы мониторинга) помогут выявить пиковые нагрузки и моменты нехватки ресурсов, которые могут совпадать с появлением ошибки.
Большинство проблем с временными таблицами в 1С на PostgreSQL часто решаются путем оптимизации параметров конфигурации СУБД. Эти настройки определяются в файле postgresql.conf. Давайте рассмотрим ключевые параметры, которые могут повлиять на стабильность работы с временными таблицами:
temp_buffers:
Этот параметр задает максимальный объем памяти, выделяемый для временных таблиц каждой сессии. Если объем временных данных превышает temp_buffers, PostgreSQL начинает сбрасывать их на диск, что значительно замедляет работу и увеличивает риск ошибок при нехватке дискового пространства или некорректной работе с файлами. Для 1С, которая активно использует временные таблицы, критически важно иметь достаточно большой объем temp_buffers.
Рекомендация: Увеличьте значение temp_buffers. В примере из форума пользователи использовали 512MB. Для высоконагруженных систем рекомендуется от 32MB до 512MB или даже выше, в зависимости от общего объема ОЗУ сервера и количества активных сессий. Устанавливайте это значение, исходя из объема оперативной памяти сервера и количества одновременно установленных соединений.
work_mem:
work_mem определяет максимальный объем памяти, используемый операциями сортировки, хеширования и некоторыми другими временными структурами данных в рамках одного запроса. Если памяти не хватает, PostgreSQL использует временные файлы на диске. Большая часть операций с временными таблицами, особенно их заполнение, сортировка и объединение, может требовать значительного объема work_mem.
Рекомендация: Увеличьте work_mem. В примере из форума было установлено 5242kB (примерно 5MB), что для некоторых операций может быть недостаточно. Обычно для 1С рекомендуется рассчитывать work_mem как общий объем ОЗУ / (32..64) или устанавливать в диапазоне от 32MB до 256MB. Помните, что это значение выделяется на каждую сессию, поэтому слишком большое значение может привести к быстрой утилизации всей оперативной памяти сервера при большом количестве одновременных подключений.
max_locks_per_transaction:
Этот параметр задает максимальное число блокировок таблиц и индексов, которые может удерживать одна транзакция. 1С-решения, особенно при проведении объемных документов или перепроведении за период, могут активно создавать и удалять временные таблицы, что требует большого количества блокировок. Если этот лимит будет превышен, транзакция может быть отменена, а временные таблицы – удалены или оставлены в некорректном состоянии.
Рекомендация: Увеличьте значение max_locks_per_transaction. В примере из форума установлено 1024, что является хорошей отправной точкой. Для решений 1С, активно использующих временные таблицы, рекомендуется значение 256 или выше. Иногда приходится увеличивать до 1024 и более.
shared_buffers:
shared_buffers определяет объем общей памяти, которую PostgreSQL использует для кэширования данных. Хотя временные таблицы не кэшируются напрямую в shared_buffers (они используют work_mem и кэш файловой системы), этот параметр критически важен для общей производительности СУБД. Недостаточный объем shared_buffers может привести к общему снижению производительности, что косвенно может усугубить проблемы с временными таблицами.
Рекомендация: Установите shared_buffers примерно в 25-30% от общего объема оперативной памяти сервера. В примере из форума указано 6256MB, что является разумным значением для сервера с 24GB ОЗУ.
max_connections:
Этот параметр определяет максимальное количество одновременных подключений к серверу баз данных. Платформа 1С, особенно в клиент-серверном режиме, может открывать большое количество соединений (как постоянных, так и кратковременных). Если этот лимит достигнут, новые соединения будут отклоняться, что может приводить к ошибкам в работе 1С.
Рекомендация: Для систем 1С рекомендуется устанавливать max_connections не менее 500-1000, в зависимости от количества пользователей и характера нагрузки.
Пример настроек в postgresql.conf:
Основываясь на рекомендациях и данных из форума, вы можете применить следующие настройки:
# Основные настройки памяти
shared_buffers = 6256MB # 25-30% от ОЗУ сервера (например, для 24GB RAM)
work_mem = 256MB # Лимит памяти для операций сортировки/хеширования на сессию
temp_buffers = 512MB # Лимит памяти для временных таблиц на сессию
# Настройки блокировок и соединений
max_locks_per_transaction = 1024 # Достаточное количество блокировок для 1С
max_connections = 500 # Максимальное количество одновременных подключений
# Дополнительные настройки для производительности
effective_cache_size = 75% ОЗУ сервера # Например, 18GB для 24GB RAM
maintenance_work_mem = 2GB # Для операций VACUUM, REINDEX и т.д.
checkpoint_timeout = 15min # Частота контрольных точек
max_wal_size = 16GB # Максимальный размер WAL-файлов
min_wal_size = 4GB # Минимальный размер WAL-файлов
После внесения изменений в postgresql.conf обязательно перезапустите службу PostgreSQL, чтобы новые настройки вступили в силу.
Одной из часто встречающихся, но неочевидных причин проблем с временными таблицами и файлами в PostgreSQL является некорректная настройка прав доступа к файловым ресурсам. Временные таблицы, даже если они создаются в памяти, могут требовать дискового пространства для временных файлов или для записи служебной информации в системные каталоги СУБД.
Один из пользователей успешно решил проблему, предоставив необходимые права доступа:
NETWORK SERVICE, SYSTEM или специально созданной учетной записи для PostgreSQL) к папке, содержащей базу данных (например, C:\Program Files\1cv8\srvinfo для 1С и C:\Program Files\PostgreSQL\9.x\data для PostgreSQL, а также пути к табличным пространствам, если они используются).Недостаточные права доступа могут проявляться "плавающим" образом, поскольку проблемы могут возникать только при определенных условиях или нагрузках, когда требуется создать новый временный файл или записать данные в системный каталог.
В некоторых случаях, особенно при работе с очень сложными или "тяжелыми" запросами, проблема может быть связана с тем, как платформа 1С строит эти запросы. Если в запросах активно используются виртуальные таблицы, такие как "СрезПоследних" или "СрезПервых", особенно в сочетании со сложными условиями или объединениями, это может приводить к неоптимальному построению планов запросов PostgreSQL и, как следствие, проблемам с временными таблицами. Для автоматического управления жизненным циклом таких таблиц в пакетных запросах можно использовать обработку для оптимизации временных таблиц.
Рекомендация: Если мы обнаруживаем, что ошибка возникает на конкретных, сложных запросах, содержащих виртуальные таблицы, можно попробовать оптимизировать их, вынося обращения к виртуальным таблицам в отдельные временные таблицы. То есть, сначала мы получаем необходимые данные из виртуальной таблицы и сохраняем их во временной таблице 1С, а затем уже используем эту временную таблицу в дальнейших, более сложных запросах.
// Пример получения данных из виртуальной таблицы во временную таблицу
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| РегистрСведенийСрезПоследних.Период КАК Период,
| РегистрСведенийСрезПоследних.Измерение1 КАК Измерение1,
| РегистрСведенийСрезПоследних.Ресурс1 КАК Ресурс1
|ПОМЕСТИТЬ ВТ_СрезПоследних
|ИЗ
| РегистрСведений.ИмяРегистра.СрезПоследних(&Дата, ) КАК РегистрСведенийСрезПоследних";
Запрос.УстановитьПараметр("Дата", ТекущаяДата());
Запрос.Выполнить();
// Далее используем ВТ_СрезПоследних в основных запросах
ЗапросОсновной = Новый Запрос;
ЗапросОсновной.Текст =
"ВЫБРАТЬ
| ВТ_СрезПоследних.Измерение1,
| Справочник.Наименование
|ИЗ
| ВТ_СрезПоследних КАК ВТ_СрезПоследних
| ЛЕВОЕ СОЕДИНЕНИЕ Справочник.ИмяСправочника КАК Справочник
| ПО ВТ_СрезПоследних.Измерение1 = Справочник.Ссылка";
Результат = ЗапросОсновной.Выполнить().Выгрузить();
Такой подход позволяет разбить сложный запрос на более мелкие, что часто упрощает работу оптимизатора PostgreSQL и делает выполнение более стабильным.
Хотя проблема была отмечена пользователями и в свежих версиях 1С и PostgreSQL, все же стоит учитывать факторы совместимости и исправлений ошибок, которые вносятся разработчиками.
Ошибка 42P01: ERROR: relation "pg_temp.ttXXX" does not exist при проведении документов в 1С на PostgreSQL является сложной и часто имеет несколько взаимосвязанных причин. Комплексный подход к ее решению включает в себя:
temp_buffers, work_mem, max_locks_per_transaction, shared_buffers и max_connections в postgresql.conf, исходя из ресурсов вашего сервера и нагрузки 1С.Применяя эти шаги, вы значительно повысите стабильность работы вашей системы 1С на PostgreSQL и сможете устранить досадные ошибки, связанные с временными таблицами.