Re: BUG #16129: Segfault in tts_virtual_materialize in logical replication worker
От | Tom Lane |
---|---|
Тема | Re: BUG #16129: Segfault in tts_virtual_materialize in logical replication worker |
Дата | |
Msg-id | 15667.1574382815@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: BUG #16129: Segfault in tts_virtual_materialize in logicalreplication worker
|
Список | pgsql-bugs |
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > On Thu, Nov 21, 2019 at 06:56:47PM -0500, Tom Lane wrote: >> "remoteslot" will contain its very own copy of the data, which >> is then summarily freed by ExecClearSlot. > But remoteslot is virtual, so it calls tts_virtual_copyslot, not the > heap one. And AFAIK tts_virtual_copyslot only copies contents of the > tts_values/tts_isnull arrays. Really? static void tts_virtual_copyslot(TupleTableSlot *dstslot, TupleTableSlot *srcslot) { ... /* make sure storage doesn't depend on external memory */ tts_virtual_materialize(dstslot); } In any case, I sure hope that Andres hasn't made the different versions of ExecCopySlot have different semantics --- if he has, he's got some explaining to do. But at least on this point, it looks to me like all three versions still satisfy the semantics that were clearly defined previously (v11 and before): /* -------------------------------- * ExecCopySlot * Copy the source slot's contents into the destination slot. * * The destination acquires a private copy that will not go away * if the source is cleared. * * The caller must ensure the slots have compatible tupdescs. * -------------------------------- */ I'm sad that we seem to have lost this specification comment, though. regards, tom lane
В списке pgsql-bugs по дате отправления: