Date: Fri, 14 Aug 2026 09:36:37 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
	Zsolt Parragi <zsolt.parragi@percona.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	jian he <jian.universality@gmail.com>
Subject: Re: MERGE/SPLIT PARTITIONS issues/questions
Message-ID: <an8n9SBOO7m9zBZx@nathan>
References: 
 <CAN4CZFNCU=t09M=+r2t9hHLJuujdM4oQ8hCK_Sx-GpfiwMAicw@mail.gmail.com>
 <CAPpHfdtckoQ6-rBRt8=sz9mf-rYTW68f7Zj8d1XMyqNSYOZOeA@mail.gmail.com>
 <CAAKRu_aTuNGfOor3xXQHGSDK9Zuz+eDJjSjU5ZuvTqROj1=BWw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAAKRu_aTuNGfOor3xXQHGSDK9Zuz+eDJjSjU5ZuvTqROj1=BWw@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/an8n9SBOO7m9zBZx%40nathan>
Precedence: bulk

On Wed, Aug 12, 2026 at 04:48:36PM -0400, Melanie Plageman wrote:
>> > 5. In (2) I mentioned replication-related inheritance questions, but
>> > it is much more generic than that, many partition specific details get
>> > lost silently:
>> > * indexes
>> > * constraints
>> > * different DEFAULTs
>> > * foreign keys
>> > * triggers
>> > * reloptions
>> > * custom tablespace
>> > * table AM
>> > * per column settings
>> > * security labels
>> > * ACLs
>> > * RLS policies
>> >
>> > Shouldn't most of these copied into split partitions, and handled
>> > properly in merges (erroring out in non trivial cases?)
>> >
>> > Silently dropping them doesn't seem like a good behavior, as it can
>> > cause many different issues:
>> > * dropping foreign keys / checks can cause data integrity issues
>> > * dropping partition specific sequences can cause later inserts to
>> > fail or silently fall back to nulls/different values
>> > * probably many other scenarios I didn't think of
>>
>> This was intended to keep patches simple enough for pg 19.  That's
>> documented that we copy properties from parent, but don't copy from
>> previous partitions(s) [1][2].  We may implement other options in
>> further releases.
> 
> I'm worried that despite the documentation, users might find this
> surprising -- and by the time they realize it happened, it might be
> too late.
> 
> [...]
> 
> The user needs to add RLS to the new leaf partitions if they want the
> same level of security, but I'm not sure that's intuitive.
> 
> Also, for merging partitions, if you merge two partitions that have
> the same RLS, after merging, the new merged partition doesn't have
> that RLS policy -- that seems confusing too

+1.  I'm looking at the current form of the documentation:

    It is the user's responsibility to setup ACL on the new partition.

Does this mean that the merged partition is accessible to PUBLIC at first?
Or that it's not accessible to anyone?  I think this could be explained in
greater detail.

    Constraints, column defaults, column generation expressions, identity
    columns, indexes, and triggers are copied from the partitioned table to
    the new partition. But extended statistics, security policies, etc,
    won't be copied from the partitioned table.

I think the "etc" is doing a lot of heavy lifting here.  Does this mean
that only the things in the first list are handled, and everything else is
not?

    When partitions are merged, any objects depending on this partition,
    such as constraints, triggers, extended statistics, etc, will be
    dropped.

Which partition does "this partition" refer to?

    Eventually, we will drop all the merged partitions (using RESTRICT
    mode) too; therefore, if any objects are still dependent on them, ALTER
    TABLE MERGE PARTITION would fail. 

I think this would be clearer if we had specific terms for the partitions
involved.  For example, we could call the partitions that are getting
merged "source partitions", and the result of the merge the "merged
partition" or "destination partition".  To me, the above sentence sounds
like we are dropping the destination/merged partition, but I'm pretty sure
that's not what it means.

Much of the above applies to SPLIT PARTITION as well.  I'm sympathetic to
the idea of keeping things restricted at first to make the project more
feasible, but this is a pretty lengthy set of limitations that IMHO
deserves more prominence in the documentation (maybe even a warning).  I
think it'd also be a good idea to call out that these limitations by go
away in future releases.

I haven't looked at the patches, but the size of the patches, and the fact
there there are apparently still rather large problems, does make me
somewhat concerned about this feature's readiness for v19.

-- 
nathan