diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2011-01-12 20:47:02 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2011-01-12 20:47:02 -0500 |
commit | d487afbb813b7ca8803e20974b9e45530a1f4ef1 (patch) | |
tree | 81c79a1546e772ad11114d705fcc3cbc3b05822a /src/backend/utils/adt/arrayfuncs.c | |
parent | 7a32ff97321408afa0ddfcae1a4a060062956d24 (diff) | |
download | postgresql-d487afbb813b7ca8803e20974b9e45530a1f4ef1.tar.gz postgresql-d487afbb813b7ca8803e20974b9e45530a1f4ef1.zip |
Fix PlanRowMark/ExecRowMark structures to handle inheritance correctly.
In an inherited UPDATE/DELETE, each target table has its own subplan,
because it might have a column set different from other targets. This
means that the resjunk columns we add to support EvalPlanQual might be
at different physical column numbers in each subplan. The EvalPlanQual
rewrite I did for 9.0 failed to account for this, resulting in possible
misbehavior or even crashes during concurrent updates to the same row,
as seen in a recent report from Gordon Shannon. Revise the data structure
so that we track resjunk column numbers separately for each subplan.
I also chose to move responsibility for identifying the physical column
numbers back to executor startup, instead of assuming that numbers derived
during preprocess_targetlist would stay valid throughout subsequent
massaging of the plan. That's a bit slower, so we might want to consider
undoing it someday; but it would complicate the patch considerably and
didn't seem justifiable in a bug fix that has to be back-patched to 9.0.
Diffstat (limited to 'src/backend/utils/adt/arrayfuncs.c')
0 files changed, 0 insertions, 0 deletions