Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

nodeModifyTable.c

  • Tom Lane's avatar
    d487afbb
    Fix PlanRowMark/ExecRowMark structures to handle inheritance correctly. · d487afbb
    Tom Lane authored
    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.
    d487afbb
    History
    Fix PlanRowMark/ExecRowMark structures to handle inheritance correctly.
    Tom Lane authored
    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.