Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

public inbox for [email protected]  
help / color / mirror / Atom feed

From: jian he <[email protected]>
To: Dmitry Koval <[email protected]>
Cc: [email protected]
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Date: Wed, 11 Jun 2025 15:28:36 +0800
Message-ID: <CACJufxHNvb6PpeGDEkzZMnKHjZrQGBHRUENKb2AwZ4N3Q8G3fg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <171085360143.2046436.7217841141682511557.pgcf@coridan.postgresql.org>
	<[email protected]>
	<CAPpHfdv2V2tsvVn5LYyrJkzmPA==vbdCEKiT8j9yaaiDTfaQtA@mail.gmail.com>
	<[email protected]>
	<CALDaNm3V5DQSbZGxhYH+3MMMm-YdgOg+RdJ-ni6D0TZx_=Xd7w@mail.gmail.com>
	<[email protected]>
	<CAPpHfduH83+CW1dBppFVjxauPFGC+-ux+Y7wB0koZJCs029SXA@mail.gmail.com>
	<[email protected]>
	<CACJufxEi_JVg+=_BSS0o+TYUE_Hq+jmga_yxxuKLSGbQiAnZDg@mail.gmail.com>
	<[email protected]>
	<CACJufxFGPLTDW55bgaBTH1uCf0=YUZUVKWFrTBvOZNYKc49MxA@mail.gmail.com>
	<CACJufxHHnJm6Jb2YQpuRU1RX__tO=JJNJ5=EUMuzif_KNxGd9A@mail.gmail.com>
	<CACJufxFkscyhak2cSr8t+EPfwv11yccfEZBBnPbX4tRc_mWkXQ@mail.gmail.com>
	<[email protected]>
	<CACJufxHRX6xQtzn+KenK3SDR2+4kUpVnO+0axforV_pohwMnFw@mail.gmail.com>
	<[email protected]>

On Wed, Jun 11, 2025 at 8:06 AM Dmitry Koval <[email protected]> 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 generated.
+      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 the
+      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 create
+      the constraints.
+     </para>

I feel like it's not fully accurate, the following is what I can come up with:
+     <para>
+ When partitions are merged, any individual objects belonging to those
+ partitions, such as constraints or statistics will be dropped. This occurs
+ 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+dCUZPhOsmVRtJUJbWU1vH248Lg0eZjhzQ@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, defaultPartOid);
    }

view thread (178+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
  In-Reply-To: <CACJufxHNvb6PpeGDEkzZMnKHjZrQGBHRUENKb2AwZ4N3Q8G3fg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox