Re: BUG #16129: Segfault in tts_virtual_materialize in logical replication worker
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Ondřej Jirman <ienieghapheoghaiwida@xff.cz>, pgsql-bugs@lists.postgresql.org, Andres Freund <andres@anarazel.de>
Date: 2019-11-22T00:33:35Z
Lists: 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
Commits
-
Add test coverage for "unchanged toast column" replication code path.
- f67b173771a0 13.0 landed
- 8b46acf7c423 10.12 landed
- 8047a7b9dd45 12.2 landed
- 785206afdf1f 11.7 landed
-
Fix bogus tuple-slot management in logical replication UPDATE handling.
- b72a44c51ad6 11.7 landed
- a2aa224e05dc 12.2 landed
- 5d3fcb53a6a8 10.12 landed
- 4d9ceb0018cc 13.0 landed