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
    a210be77
    Fix dangling-pointer problem in before-row update trigger processing. · a210be77
    Tom Lane authored
    ExecUpdate checked for whether ExecBRUpdateTriggers had returned a new
    tuple value by seeing if the returned tuple was pointer-equal to the old
    one.  But the "old one" was in estate->es_junkFilter's result slot, which
    would be scribbled on if we had done an EvalPlanQual update in response to
    a concurrent update of the target tuple; therefore we were comparing a
    dangling pointer to a live one.  Given the right set of circumstances we
    could get a false match, resulting in not forcing the tuple to be stored in
    the slot we thought it was stored in.  In the case reported by Maxim Boguk
    in bug #5798, this led to "cannot extract system attribute from virtual
    tuple" failures when trying to do "RETURNING ctid".  I believe there is a
    very-low-probability chance of more serious errors, such as generating
    incorrect index entries based on the original rather than the
    trigger-modified version of the row.
    
    In HEAD, change all of ExecBRInsertTriggers, ExecIRInsertTriggers,
    ExecBRUpdateTriggers, and ExecIRUpdateTriggers so that they continue to
    have similar APIs.  In the back branches I just changed
    ExecBRUpdateTriggers, since there is no bug in the ExecBRInsertTriggers
    case.
    a210be77
    History
    Fix dangling-pointer problem in before-row update trigger processing.
    Tom Lane authored
    ExecUpdate checked for whether ExecBRUpdateTriggers had returned a new
    tuple value by seeing if the returned tuple was pointer-equal to the old
    one.  But the "old one" was in estate->es_junkFilter's result slot, which
    would be scribbled on if we had done an EvalPlanQual update in response to
    a concurrent update of the target tuple; therefore we were comparing a
    dangling pointer to a live one.  Given the right set of circumstances we
    could get a false match, resulting in not forcing the tuple to be stored in
    the slot we thought it was stored in.  In the case reported by Maxim Boguk
    in bug #5798, this led to "cannot extract system attribute from virtual
    tuple" failures when trying to do "RETURNING ctid".  I believe there is a
    very-low-probability chance of more serious errors, such as generating
    incorrect index entries based on the original rather than the
    trigger-modified version of the row.
    
    In HEAD, change all of ExecBRInsertTriggers, ExecIRInsertTriggers,
    ExecBRUpdateTriggers, and ExecIRUpdateTriggers so that they continue to
    have similar APIs.  In the back branches I just changed
    ExecBRUpdateTriggers, since there is no bug in the ExecBRInsertTriggers
    case.