Re: MERGE/SPLIT PARTITIONS issues/questions

> On 12 Aug 2026, at 22:48, Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
> On Mon, Aug 3, 2026 at 6:03 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>>
>> On Thu, Jul 23, 2026 at 1:59 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> 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.

Apart from the obviously dangerous ones like RLS and ACL, silently dropping the
table AM may induce side-effects which are hard for us to even reason about
since they are external to the core code. AFAICT we don't document that a
table can move out of the TAM, if even briefly.

I don't disagree with limiting scope to make a patch reviewable in a first
version, but I think this should do so by rejecting any cases where options are
silently dropped instead. What if the code checks both partitions for being
equal to the parent, and only allow a MERGE when all parameters can be kept due
to them being equal?

It's true that the behaviour is documented, but I don't think it's entirely
easy to grasp as the list of things being dropped is incomplete with an "etc":

"But extended statistics, security policies, etc, won't be copied from
the partitioned table."

> ...
>
> 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.

It's not, and it quite easily will leave the data without the intended
protection during a window.

> 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

I would rank this as even more unintuitive than the previous case, as a user I
would expect the new partition to have the shared policy.

Could we make this safe by restricting to the cases where partitions match the
parent and we can make them not drop characteristics? If we want to expand
which differences can be handled in a safe manner in 20 then we can revisit,
rather than being very lax now and try to restrict later.

--
Daniel Gustafsson