Dead code as a result of plan cache invalidation?
Should this case at heaptuple.c:1606 be turned into an elog() now that we have
plan cache invalidation? If it "can't" happen then it's probably better that
we find out if it does happen rather than silently run the old plan and return
nulls.
/*
* If the attribute's column has been dropped, we force a NULL result.
* This case should not happen in normal use, but it could happen if we
* are executing a plan cached before the column was dropped.
*/
if (tupleDesc->attrs[attnum - 1]->attisdropped)
{
*isnull = true;
return (Datum) 0;
}
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
Should this case at heaptuple.c:1606 be turned into an elog() now that we have
plan cache invalidation?
No, I think it's good as-is. Reading the column as null is the correct
behavior.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
Gregory Stark <stark@enterprisedb.com> writes:
Should this case at heaptuple.c:1606 be turned into an elog() now that we have
plan cache invalidation?No, I think it's good as-is. Reading the column as null is the correct
behavior.
Isn't the correct behaviour that you would have been prevented from executing
that plan and forced to replan your query?
Let me put it another way, how would I write a test case to cover these lines
of code and not receive an error from replanning?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
Let me put it another way, how would I write a test case to cover these lines
of code and not receive an error from replanning?
"Hard to get to" is not the same as "dead code". An example is that
third-party add-ons might re-use plans that are not completely up to
date, if they've not been rewritten to use the plan cache.
regards, tom lane