Re: [BUG]: segfault during update

Hi,

On 11/8/20 6:46 PM, Tom Lane wrote:
> I wrote:
>> Yeah, this is sufficient reason why we must use the more invasive
>> patch on those branches.  What I'm wondering now is if there's a
>> way to break even-older branches based on failure to handle dropped
>> columns here.
> After tracing through the example in v11, I see why those branches
> are not broken: when ExecBRUpdateTriggers decides to return the
> trigger-returned tuple, it sticks it into a target slot like this:
>
>          /*
>           * Return the modified tuple using the es_trig_tuple_slot.  We assume
>           * the tuple was allocated in per-tuple memory context, and therefore
>           * will go away by itself. The tuple table slot should not try to
>           * clear it.
>           */
>          TupleTableSlot *newslot = estate->es_trig_tuple_slot;
>          TupleDesc    tupdesc = RelationGetDescr(relinfo->ri_RelationDesc);
>
>          if (newslot->tts_tupleDescriptor != tupdesc)
>              ExecSetSlotDescriptor(newslot, tupdesc);
>          ExecStoreTuple(newtuple, newslot, InvalidBuffer, false);
>
> So the slot that ExecConstraints et al will be working with contains
> the relation's actual tuple descriptor, not the approximate descr
> obtained by looking at the plan tlist.
>
> This logic is entirely gone in v12, which confirms my instinct that
> there was something about Andres' slot-manipulation changes that
> broke this scenario.  In v12 we end up using the junkfilter's output
> slot, which does not have a sufficiently accurate tupdesc to deal with
> an on-disk tuple rather than one constructed by the executor.
>
> So I'll go see about back-patching 20d3fe900.

Thanks for the back-patching!

Bertrand