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

nodeLockRows.c

Blame
    • 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.