Estoy agregando esta respuesta para cualquiera que aterrice aquí ERROR: cached plan must not change result type
buscando en Google cuando intente resolver el problema en el contexto de una aplicación Java / JDBC.
Pude reproducir de manera confiable el error ejecutando actualizaciones de esquema (es decir, declaraciones DDL) mientras se ejecutaba mi aplicación de back-end que usaba la base de datos. Si la aplicación consultaba una tabla que había sido modificada por la actualización del esquema (es decir, la aplicación ejecutó consultas antes y después de la actualización en una tabla modificada), el controlador de postgres devolvería este error porque aparentemente almacena en caché algunos detalles del esquema.
Puede evitar el problema configurando su pgjdbc
controlador con autosave=conservative
. Con esta opción, el controlador podrá vaciar cualquier detalle que esté almacenando en caché y no debería tener que hacer rebotar su servidor o vaciar su grupo de conexiones o cualquier solución alternativa que se le haya ocurrido.
Reproducido en Postgres 9.6 (AWS RDS) y mi prueba inicial parece indicar que el problema está completamente resuelto con esta opción.
Documentación: https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters
Puede consultar el pgjdbc
número 451 de Github para obtener más detalles y el historial del problema.
Los usuarios de JRuby ActiveRecords ven esto: https://github.com/jruby/activerecord-jdbc-adapter/blob/master/lib/arjdbc/postgresql/connection_methods.rb#L60
Nota sobre el rendimiento:
De acuerdo con los problemas de rendimiento informados en el enlace anterior, debe realizar algunas pruebas de rendimiento / carga / remojo de su aplicación antes de activarla a ciegas.
Al realizar pruebas de rendimiento en mi propia aplicación que se ejecuta en una Postgres 10
instancia de AWS RDS , habilitar la conservative
configuración da como resultado un uso adicional de la CPU en el servidor de la base de datos. Sin embargo, no fue mucho, solo pude ver que la autosave
funcionalidad se mostraba usando una cantidad medible de CPU después de haber ajustado cada consulta que estaba usando mi prueba de carga y comencé a presionar la prueba de carga con fuerza.