MIME-Version: 1.0
References: 
 <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org>
 <4e2764f7-f6be-478f-8d7f-f921dbd10f5f@postgrespro.ru>
 <CAPpHfdv2V2tsvVn5LYyrJkzmPA==vbdCEKiT8j9yaaiDTfaQtA@mail.gmail.com>
 <ff30dc7e-ebca-42a2-9d49-a66c9a3c7ee5@postgrespro.ru>
 <CALDaNm3V5DQSbZGxhYH+3MMMm-YdgOg+RdJ-ni6D0TZx_=Xd7w@mail.gmail.com>
 <7fdaf3e8-4c05-4739-bee6-98acc068d1c7@postgrespro.ru>
 <CAPpHfduH83+CW1dBppFVjxauPFGC+-ux+Y7wB0koZJCs029SXA@mail.gmail.com>
 <4433b492-9e97-4334-96d9-ddaaa5083099@postgrespro.ru>
 <CACJufxEi_JVg+=_BSS0o+TYUE_Hq+jmga_yxxuKLSGbQiAnZDg@mail.gmail.com>
 <67ecf5fb-e63d-4284-be75-d0479eef81aa@postgrespro.ru>
 <CACJufxFGPLTDW55bgaBTH1uCf0=YUZUVKWFrTBvOZNYKc49MxA@mail.gmail.com>
 <CACJufxHHnJm6Jb2YQpuRU1RX__tO=JJNJ5=EUMuzif_KNxGd9A@mail.gmail.com>
 <CACJufxFkscyhak2cSr8t+EPfwv11yccfEZBBnPbX4tRc_mWkXQ@mail.gmail.com>
 <884bcf9e-d6e3-4b0c-8dcb-7f2110070ac9@postgrespro.ru>
 <CACJufxHRX6xQtzn+KenK3SDR2+4kUpVnO+0axforV_pohwMnFw@mail.gmail.com>
 <1e74c9fd-830e-4544-b0de-e49ea4b04029@postgrespro.ru>
In-Reply-To: <1e74c9fd-830e-4544-b0de-e49ea4b04029@postgrespro.ru>
From: jian he <jian.universality@gmail.com>
Date: Wed, 11 Jun 2025 15:28:36 +0800
Message-ID: 
 <CACJufxHNvb6PpeGDEkzZMnKHjZrQGBHRUENKb2AwZ4N3Q8G3fg@mail.gmail.com>
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
To: Dmitry Koval <d.koval@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CACJufxHNvb6PpeGDEkzZMnKHjZrQGBHRUENKb2AwZ4N3Q8G3fg%40mail.gmail.com>
Precedence: bulk

On Wed, Jun 11, 2025 at 8:06=E2=80=AFAM Dmitry Koval <d.koval@postgrespro.r=
u> wrote:
>
>  >Do getAttributesList need to care about pg_attribute.attidentity?
>  >currently MERGE PARTITION seems to work fine with identity columns,
>  >this issue i didn't dig deeper.
>
> Probably after commit [3] partition's identity columns shares the
> identity space (i.e. underlying sequence) as the corresponding
> columns of the partitioned table. So call BuildDescForRelation in
> createPartitionTable function should copy pg_attribute.attidentity
> for new partition.
>
but BuildDescForRelation is based on getAttributesList,
in getAttributesList, assign pg_attribute.attidentity to def->identity
should be safe, IMHO.

+     <para>
+      If merged partitions have different owners, an error will be generat=
ed.
+      The owner of the merged partitions will be the owner of the new
partition.
+     </para>
+     <para>
+      It is the user's responsibility to setup <acronym>ACL</acronym> on t=
he
+      new partition.
+     </para>
since they <para> are related, these two can be one <para>?


+     <para>
+      If merged partitions have individual constraints, those constraints =
will
+      be dropped because command uses partitioned table as a model to crea=
te
+      the constraints.
+     </para>

I feel like it's not fully accurate, the following is what I can come up wi=
th:
+     <para>
+ When partitions are merged, any individual objects belonging to those
+ partitions, such as constraints or statistics will be dropped. This occur=
s
+ because ALTER TABLE MERGE PARTITIONS uses the partitioned table itself as=
 the
+ template to define these objects.
+     </para>


>
>  >I am wondering right after createPartitionTable,
>  >do we need a CommandCounterIncrement?
>  >because later moveMergedTablesRows will use the output of
>  >createPartitionTable.
>
> We call CommandCounterIncrement in createPartitionTable function right
> after heap_create_with_catalog (same code in create_toast_table,
> make_new_heap, DefineRelation functions). We need an additional
> CommandCounterIncrement call in case we use objects created after this
> point. But we probably don't use these objects (in function
> moveMergedTablesRows too).
>
As mentioned in the previous thread [1], moveMergedTablesRows need
latest relcache entry for newPartRel. so I guess, put one
CommandCounterIncrement at the end of createPartitionTable
should be fine, which I already did in [1].
[1]: https://postgr.es/m/CACJufxH3mfNYfHy9+dCUZPhOsmVRtJUJbWU1vH248Lg0eZjhz=
Q@mail.gmail.com

> 3.
>  >I only want to allow HEAP_TABLE_AM_OID to be used
>  >in the merge partition,
>  >I guess that would avoid unintended consequences.
>
> Thanks for the clarification. Isn't this limitation too strong?
> It is very likely that the user will create an AM based on
> HEAP_TABLE_AM_OID, in which case the code should work.
>
ok.


if you looking at ATExecDetachPartition, we have:
    /*
     * Detaching the partition might involve TOAST table access, so ensure =
we
     * have a valid snapshot.
     */
    PushActiveSnapshot(GetTransactionSnapshot());
    /* Do the final part of detaching */
    DetachPartitionFinalize(rel, partRel, concurrent, defaultPartOid);
    PopActiveSnapshot();

do we need do the same to the following DetachPartitionFinalize:
    foreach_ptr(RelationData, mergingPartition, mergingPartitionsList)
    {
        /* Remove the pg_inherits row first. */
        RemoveInheritance(mergingPartition, rel, false);
        /* Do the final part of detaching. */
        DetachPartitionFinalize(rel, mergingPartition, false, defaultPartOi=
d);
    }