From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Daniel Heath" <daniel(at)heath(dot)cc> |
Cc: | pgsql-novice(at)lists(dot)postgresql(dot)org |
Subject: | Re: Prepared statement invalidation |
Date: | 2021-04-16 00:17:01 |
Message-ID: | 3969078.1618532221@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
"Daniel Heath" <daniel(at)heath(dot)cc> writes:
> I've found that when I add a new column, I sometimes get a spike of errors on the application side due to prepared statement query plans getting invalidated, causing transactions to rollback.
> The error is:
> ERROR: cached plan must not change result type
> Is there a way to make postgres recalculate the query plan instead of failing the transaction when a new column is added?
No. It'd be easy enough to remove that restriction on the server side,
but we're afraid that it would break applications, which probably aren't
expecting the result rowtype of a prepared query to be different from what
they were told (perhaps only milliseconds earlier).
I'd say the short answer is "don't use prepared queries, or if you do,
spell out the columns you want instead of saying SELECT *".
regards, tom lane
> Thanks,
> Daniel Heath
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Heath | 2021-04-16 06:16:45 | Re: Prepared statement invalidation |
Previous Message | Daniel Heath | 2021-04-16 00:09:38 | Prepared statement invalidation |