Я добавляю этот ответ для любого, кто приземлится здесь, прибегая к помощи 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 показала использование измеримого количества ЦП только после того, как я настроил каждый отдельный запрос, который использовался в моем нагрузочном тесте, и начал усиленно толкать нагрузочный тест.