On 2023-Feb-14, PG Bug reporting form wrote:
> When executing the following queries with valgrind:
> echo "
> CREATE TABLE source (sid integer);
> INSERT INTO source VALUES (1);
> CREATE TABLE target (tid integer, tval integer);
> INSERT INTO target VALUES (1, 1);
> " | psql
> At nodeModifyTable.c:2992 I see:
> if (!TupIsNull(context->cpUpdateRetrySlot))
>
> It looks like cpUpdateRetrySlot was not initialized on the context creation
> in ExecModifyTable(), and ExecCrossPartitionUpdate(), where it could get a
> value, just not called for this case.
Hmm, yeah: because this is not a partitioned table, we are definitely
not expecting that cpUpdateRetrySlot will be set. Can you still
reproduce the problem with the attached patch?
I'm not sure that the location of the initialization is best. My first
impulse was to add it in line 3618, with the "Set global context" lines;
but then I think it's possible for one tuple of a partition to be routed
correctly and a later one that is concurrently updated suffer from an
improper value in cpUpdateRetrySlot.
Also, the comment is not great ...
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
