New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERROR: cached plan must not change result type #1038
Comments
Yes, after each migration that may change the result. For example, it is clear that A patch for postgresql is proposed to remove this limitation: https://commitfest.postgresql.org/47/4518/ |
@Melkij Thanks for your kindly respond 馃拹 . do we have better ways other than mannully open the admin console and run reconnect, I mean, when you have pgbouncer on mutiple different servers, like, before the code deployment start, execute a shell script to connect to the admin console and run reconnect? |
It seems that after @knizhnik's recent changes under PR #972, we can call alter table sample alter column col type;
DEALLOCATE ALL; But this is just a theory, @knizhnik or @JelteF could help confirm or deny this |
|
Hi,
We runs mutiple Ruby on Rails Project and started to using pgbouncer recently, it is a good tool 馃憤.
However we are having an issue that has documented: ERROR: cached plan must not change result type
You can avoid such errors by not having multiple clients that use the exact
same query string in a prepared statement, but expecting different argument or
result types. One of the most common ways of running into this issue is during
a DDL migration where you add a new column or change a column type on an
existing table. In those cases you can run
RECONNECT
on the PgBouncer adminconsole after doing the migration to force a re-prepare of the query and make
the error goes away.
My question is that do we need to mannully run the RECONNECT command on every pgbouncer client server every time after the database migration?
The text was updated successfully, but these errors were encountered: