diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2011-01-12 20:47:09 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2011-01-12 20:47:09 -0500 |
commit | fed8dcdb84d255088d22efa3156a193f3399e792 (patch) | |
tree | 8262474db57695b73d2fcdb0975a5f89f5573307 /src/pl/plpython/plpython.c | |
parent | a1ed4cf6ca6ee2115d9f618ed7930a97842042a8 (diff) | |
download | postgresql-fed8dcdb84d255088d22efa3156a193f3399e792.tar.gz postgresql-fed8dcdb84d255088d22efa3156a193f3399e792.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/pl/plpython/plpython.c')
0 files changed, 0 insertions, 0 deletions