Postgres: "ОШИБКА: кэшированный план не должен изменять тип результата"

Question

Это исключение выдается сервером PostgreSQL 8.3.7 в мое приложение. Кто-нибудь знает, что означает эта ошибка и что я могу с этим сделать?

ERROR:  cached plan must not change result type
STATEMENT:  select code,is_deprecated from country where code=$1

Answer 1

Я выяснил, что было причиной этой ошибки.

Мое приложение открыло соединение с базой данных и подготовило инструкцию SELECT для выполнения.

Между тем, другой скрипт модифицировал таблицу базы данных, изменив тип данных одного из столбцов, возвращаемых в приведенном выше операторе SELECT.

Я решил эту проблему, перезапустив приложение после изменения таблицы базы данных. Это сбрасывает соединение с базой данных, позволяя подготовленному оператору выполнить без ошибок.

Answer 2

Я добавляю этот ответ для любого, кто приземлится здесь, прибегая к помощи ERROR: cached plan must not change result type,

Вы можете избежать этой проблемы, настроив pgjdbc водитель с autosave=conservative, С этой опцией вам не нужно отказывать вашему серверу, сбрасывать пул соединений или какой-либо обходной путь, который вы, возможно, придумали.

Воспроизведено на Postgres 9.6 (AWS RDS), и мое первоначальное тестирование, похоже, указывает, что проблема полностью решена с помощью этой опции.

Документация: https://jdbc.postgresql.org/documentation/head/connect.html

Вы можете посмотреть на pgjdbc Github выпуск 451 для более подробной информации и истории вопроса.

Обратите внимание, что в соответствии с сообщениями о проблемах производительности, приведенными в приведенной выше ссылке, вы должны выполнить некоторое тестирование производительности / нагрузки / выдержки в своем приложении, прежде чем включать его вслепую.

Answer 3

Для нас мы столкнулись с аналогичной проблемой. Наше приложение работает с несколькими схемами. Эта проблема возникала всякий раз, когда мы вносили изменения в схему.

Установка параметра prepareThreshold=0 внутри параметра JDBC отключает кеширование операторов на уровне базы данных. Это решило проблему для нас.

Answer 4

Я получил эту ошибку, я вручную выполнил неудачный запрос выбора и исправил ошибку.

Answer 5

Я получил эту ошибку при разработке plpgsql (удаление и создание функции) в моей локальной базе данных без других подключений.

Я думаю, что причина в том, что я использовал параметр OUT функции с тем же именем, что и столбец в таблице внутри LOOP.

Мне нужно отключиться и снова подключиться, чтобы исправить.

ПостгреСБЛ 16.

Answer 6

Если у вас есть приложение JPA с спящим режимом или другим поставщиком и вы меняете тип столбца в домене, например увеличиваете длину столбца одного атрибута, вам придется вручную изменить столбец в базе данных, чтобы отразить это изменение:

      alter table table_name alter column column_name type character varying(2000);