Thread

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Dmitry Koval <d.koval@postgrespro.ru> — 2025-10-27T23:12:29Z

Hi Alexander!

1.
 > The second CommandCounterIncrement() is needed to make the renamed
 > relation visible within our transaction.  Why do we need the first
 >one?  I see tests pass without it.

It's strange. If I comment the first "CommandCounterIncrement();", in block
-----------------------------------------------------------------------
/*
  * We must bump the command counter to make the split partition tuple
  * visible for renaming.
  */
CommandCounterIncrement();
/* Rename partition. */
sprintf(tmpRelName, "split-%u-%X-tmp", RelationGetRelid(rel), ...);
RenameRelationInternal(splitRelOid, tmpRelName, true, false);
/*
  * We must bump the command counter to make the split partition tuple
  * visible after renaming.
  */
CommandCounterIncrement();
-----------------------------------------------------------------------
, I got the error "ERROR: tuple already updated by self" in the
partition_split.sql test (Ubuntu). If I comment the second
"CommandCounterIncrement();", I got the error "ERROR:  relation
"sales_others" already exists" in the same test.


2.
 >The branch handling null value in the outer loop, uses null2 flag from
 >the inner loop.  I think for the null value of the outer loop we still
 >need to run inner loop to search for the matching null value.

This code looks a little confusing, but it probably works correctly.
This can be verified using two typical examples:
-----------------------------------------------------------------------
list1: (NULL, 1)
list2: (2, NULL)

(1) isnull1 = true, (2) "if (isnull1) lappend(NULL)"
-----------------------------------------------------------------------
list1: (1, NULL)
list2: (NULL, 2)

(1) isnull2 = true, (2) "if (isnull2) lappend(NULL)"
-----------------------------------------------------------------------
In both cases, we return from the function immediately after lappend.
This works because we need to find exactly one repeating value.


-- 
With best regards,
Dmitry Koval

Postgres Professional: http://postgrespro.com