ERROR after changing length or type in postgress


after changing a field type or the length of the field. We see users getting the following error:

ERROR 0A000 (feature_not_supported): cached plan must not change result type

This error seems to show up only once though. After a refresh of the page, the error is gone.

It hits the user who first hits a certain route. So there seems to be some cache involved there the old type / length collides with the new one.

What can i do?


@Max: This error happens if for example you run application and in another terminal you change any table. I think that you have application already started and executed mix ecto.migrate. You need to restart app or your connection to database after migration finishes, but I don’t know when to detect it. I suggest to not complicate it and simply restart application.

Thanks for the input. But it seems that only a db (aws rds) restart seems to solve the problem. Restarting the app or even the app server didn´t help.

@Max: hmm, strange
I found solution for it at: stackoverflow.
I don’t know what you exactly do, but I through about:

  1. You started your app
  2. Your app (or you manually) changed database structure
  3. From this topic we know that connection needs to be updated (something like per connection cache?)

I don’t know what deployment tools you were using, but from what I can imagine you only need to restart your app (or maybe proxy if any) that holds connection to database. Once your app setups new connection your app should see new database structure.

Another words: you do not need to restart database after you call MIX_ENV=prod mix ecto.migrate (when your app is not started), do you?

So you only need to restart connection between your app and database. What you were doing is permanent close all connections to that database. Maybe there was a connection cache (remember database structure for IP?) or something, but in normal case you do not need to restart Amazon RDS or maybe you are using “special” database that needs a restart. Out of curiosity: what database are you using for that application? I don’t have such a problem with latest PostgreSQL.

For deployment i use Distillery. I´m almost sure i´ve tried to restart the app without any success. Perhaps the restart itself didn´t work without getting noticed by me. I will try your advice next time again.