Обсуждение: cached plan must not change result type
Hi all,
Our client noticed a problem which occurred so far twice, but might be having quite significant impact on our application processing in production: ResStatus: PGRES_FATAL_ERROR transaction. ErrorMessage: ERROR: cached plan must not change result type.
Reading through the documentation problem is quite understood on our side, while most probably caused by our implementation of Virtual Partitioning on postgresql, by triggering database schema update through the application upgrade procedure or simply by altering one of the tables manually - so far so good.
Now, our developers came with a solution where we check return value from PQresultStatus(x) for PGRES_FATAL_ERROR and then if the error message from PQresultErrorMessage(x) contains "cached plan must not change result type" we delete statement and prepare it again.
I would like to ask, would you see this solution in general as fine, or is there any better way to achieve this? I particularly dislike the part when we are trying matching return string on "cached plan must not change result type" as error messages might change (e.g. situations using different locales), is there any way how to get around this e.g. with enumerator?
Thank you,
Jan
Our client noticed a problem which occurred so far twice, but might be having quite significant impact on our application processing in production: ResStatus: PGRES_FATAL_ERROR transaction. ErrorMessage: ERROR: cached plan must not change result type.
Reading through the documentation problem is quite understood on our side, while most probably caused by our implementation of Virtual Partitioning on postgresql, by triggering database schema update through the application upgrade procedure or simply by altering one of the tables manually - so far so good.
Now, our developers came with a solution where we check return value from PQresultStatus(x) for PGRES_FATAL_ERROR and then if the error message from PQresultErrorMessage(x) contains "cached plan must not change result type" we delete statement and prepare it again.
I would like to ask, would you see this solution in general as fine, or is there any better way to achieve this? I particularly dislike the part when we are trying matching return string on "cached plan must not change result type" as error messages might change (e.g. situations using different locales), is there any way how to get around this e.g. with enumerator?
Thank you,
Jan
I would like to ask, would you see this solution in general as fine, or is there any better way to achieve this? I particularly dislike the part when we are trying matching return string on "cached plan must not change result type" as error messages might change (e.g. situations using different locales), is there any way how to get around this e.g. with enumerator?
Source code says that the errcode being returned is "Feature Not Supported" which seems unreasonably broad, I'd probably stick with message text parsing. If you have locale concerns you could just check for one of the 11 different translations that are presently provided. Or combine them, checking for the error code value first (which probably would be rare enough in production code to be usable) then fall back to the description.
David J.