Message-ID: <b96a16a5-02de-4cc2-afb4-fbccba43eb54@postgrespro.ru>
Date: Tue, 28 Oct 2025 02:12:29 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
References: 
 <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org>
 <e5ecd88e-4087-49cc-8c72-26c6c01f760b@postgrespro.ru>
 <CACJufxGWCVf5r9kE-z6MyR2b+wkaU15Q5m2tKz4cvBhYX3-x1g@mail.gmail.com>
 <f1c96833-6d37-46ac-ae9b-6d48ec55dd4c@postgrespro.ru>
 <CAPpHfdshkf0C2h09S00TVB8h3x8UT+GZyQ6LK2WGg1hOjnNE4g@mail.gmail.com>
 <CAPpHfdsh_jPZ6-2JtWoFeZravVQYY4cYCcnKXQW6KxEx+F5vxg@mail.gmail.com>
 <2643645f-2a02-43de-9321-c995ab1b7ef8@postgrespro.ru>
 <CACJufxF1Hfx1PST7pCLrKkGcjHEn2A51znXmYwVccnt5GDORcw@mail.gmail.com>
 <57a94d8a-d7b6-4c5e-9001-be1cd403b172@postgrespro.ru>
 <54414932-9E82-47AA-902B-2DED18F07F64@gmail.com>
 <e7da0ceb-8a01-4856-8c87-f87f09b4a9ad@postgrespro.ru>
 <CACJufxET9Qe-=zJtjGrKPr7-1QbVcP9y-vJU9CMEDfPGt_dbyg@mail.gmail.com>
 <3280c458-a886-4c58-8e2b-4d220b73161d@postgrespro.ru>
 <CACJufxEBvrtcOWyX2NMwOCvb2ZvaRGaGeiMQpUD=yxL6ncBFOg@mail.gmail.com>
 <dbe8e3ac-0b85-4809-bfaf-1d11f3c9d814@postgrespro.ru>
 <CAPpHfdvSBR+sbsRCAybN949tOGArQvMH2QeDXf2L=7NDMNbJfw@mail.gmail.com>
Content-Language: en-US
From: Dmitry Koval <d.koval@postgrespro.ru>
In-Reply-To: 
 <CAPpHfdvSBR+sbsRCAybN949tOGArQvMH2QeDXf2L=7NDMNbJfw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b96a16a5-02de-4cc2-afb4-fbccba43eb54%40postgrespro.ru>
Precedence: bulk

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