Andres Freund <andres@anarazel.de> writes:
> On 2019-11-05 12:38:32 -0500, Tom Lane wrote:
>> So pretty clearly, this slot has a null bslot->base.tuple pointer and
>> yet its TTS_FLAG_SHOULDFREE flag is set.
> Hm. It seems quite likely that this is yet another report of:
> commit d986d4e87f61c68f52c68ebc274960dc664b7b4e
> Fix crash caused by EPQ happening with a before update trigger present.
> The copying of a slot into itself yielded precisely this symptom, a slot
> with shouldfree set, but without a tuple associated.
Thomas, can you try with that patch and see if it fixes the problem
for you? We're quite close to 12.1 release, so if there's more to fix,
it'd be better to find out ASAP.
Note that this theory requires that the query we see being executed within
a BEFORE UPDATE trigger had itself fired a BEFORE UPDATE trigger, and that
there'd been concurrent commits causing EPQ to run. That doesn't seem
exactly implausible, but it's data not evident in your report.
>> Wondering about how that could be, I notice that execTuples.c seems
>> to have a bad coding pattern of setting TTS_FLAG_SHOULDFREE *before*
>> the pointer is valid. Eg, in tts_buffer_heap_materialize, a failure
>> in heap_form_tuple would leave the slot in an inconsistent state.
>> I'm not sure that that explains this report, because we typically
>> would not run ExecutorEnd on a plan tree that had failed, but I'm
>> still strongly inclined to run around and move those flag-setting
>> steps down a bit. Andres, any objection?
> No objection here.
OK, I'll take a look at that tomorrow or so. It's probably just
cosmetic, but it makes me itch anyway.
regards, tom lane