Это исключение вызывается сервером PostgreSQL 8.3.7 для моего приложения. Кто-нибудь знает, что означает эта ошибка и что я могу с этим сделать?
ERROR: cached plan must not change result type
STATEMENT: select code,is_deprecated from country where code=$1
Я понял, что вызывало эту ошибку.
Мое приложение открыло соединение с базой данных и подготовило оператор SELECT для выполнения.
Между тем другой script изменял таблицу базы данных, изменяя тип данных одного из столбцов, возвращаемых в приведенном выше операторе SELECT.
Я решил это, перезапустив приложение после изменения таблицы базы данных. Это reset соединение с базой данных, позволяющее готовому оператору выполнить без ошибок.
Я добавляю этот ответ для любого, кто приземлится здесь, прибегая к помощи ERROR: cached plan must not change result type при попытке решить проблему в контексте приложения Java/JDBC.
Я смог надежно воспроизвести ошибку, запустив обновления схемы (то есть операторы DDL), когда мое внутреннее приложение, которое использовало БД, работало. Если приложение запрашивает таблицу, которая была изменена обновлением схемы (т.е. приложение выполняло запросы до и после обновления измененной таблицы), драйвер postgres вернул бы эту ошибку, потому что, очевидно, он кэширует некоторые детали схемы.
Вы можете избежать этой проблемы, настроив драйвер pgjdbc с помощью autosave=conservative. С помощью этой опции драйвер сможет сбрасывать любые данные, которые он кэширует, и вам не нужно сбрасывать нагрузку с вашего сервера, сбрасывать пул подключений или какой-либо обходной путь, с которым вы, возможно, столкнулись.
Воспроизводится на Postgres 9.6 (AWS RDS), и мое первоначальное тестирование, похоже, указывает на то, что проблема полностью решена с помощью этой опции.
Документация: https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters
Более подробную информацию и историю проблемы вы можете найти в pgjdbc выпуске Github 451.
Примечание по производительности:
Согласно сообщениям о проблемах производительности, приведенным в приведенной выше ссылке, вам следует провести некоторое тестирование производительности/нагрузки/выдержки приложения, прежде чем включать его вслепую.
При выполнении тестирования производительности моего собственного приложения, работающего на экземпляре AWS RDS Postgres 10, включение параметра conservative приводит к дополнительной загрузке ЦП на сервере базы данных. Хотя это было немного, я мог видеть, что функциональность autosave показала, что он использует измеримое количество ЦП, после того, как я настроил каждый отдельный запрос, который использовал мой нагрузочный тест, и начал сильно нагружать нагрузочный тест.