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