Re: BUG #16129: Segfault in tts_virtual_materialize in logical replication worker

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On Thu, Nov 21, 2019 at 05:37:25PM -0500, Tom Lane wrote:
> I don't think that's quite true. After the ExecCopySlot call, the
> pass-by-ref Datums in remoteslot will point to a tuple attached to
> localslot. But it does not pass the tuple 'ownership' to the remoteslot,
> i.e. the flag TTS_FLAG_SHOULDFREE won't be set, i.e. the tuple won't be
> freed.

Nope:

static void
tts_heap_copyslot(TupleTableSlot *dstslot, TupleTableSlot *srcslot)
{
    HeapTuple    tuple;
    MemoryContext oldcontext;

    oldcontext = MemoryContextSwitchTo(dstslot->tts_mcxt);
    tuple = ExecCopySlotHeapTuple(srcslot);
    MemoryContextSwitchTo(oldcontext);

    ExecStoreHeapTuple(tuple, dstslot, true);
}

"remoteslot" will contain its very own copy of the data, which
is then summarily freed by ExecClearSlot.

>> I imagine the only reason this code has gotten past the valgrind
>> animals is that we're not testing cases where non-replaced columns
>> in the subscriber table are of pass-by-ref types.

> I haven't checked, but I'd imagine we actually do such tests. I've
> however tried to reproduce this, unsuccessfully.

I did check, and we don't.  See patch.

It's possible that the OP is seeing some different problem,
but I can definitely demonstrate that there is a problem
that this change fixes.

            regards, tom lane