Re: MERGE/SPLIT PARTITIONS issues/questions

On Thu, Aug 20, 2026 at 10:42 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> On Wed, Aug 19, 2026 at 7:58 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >
> > Agree on your corrections expect for deleteSplitPartitionContext(): it
> > still have resources to free. The revised patchset is attached.
> >
>
> Hi.
>
> -- SPLIT PARTITION rejects a partition with row-level security of its own, for
> -- the same reason as MERGE.
> CREATE TABLE t (i int, secret bool) PARTITION BY RANGE (i);
> CREATE TABLE tp_0_2 PARTITION OF t FOR VALUES FROM (0) TO (2);
> ALTER TABLE tp_0_2 ENABLE ROW LEVEL SECURITY;
> CREATE POLICY hide_secret ON tp_0_2 FOR SELECT USING (secret IS NOT TRUE);
> ALTER TABLE t SPLIT PARTITION tp_0_2 INTO
> (PARTITION tp_0_1 FOR VALUES FROM (0) TO (1),
> PARTITION tp_1_2 FOR VALUES FROM (1) TO (2)); -- fails
> ERROR: cannot merge or split partition "tp_0_2" that has row-level
> security enabled
> DETAIL: Row-level security is not carried over to the new partition,
> which would expose rows that the partition currently hides.
> HINT: Disable row-level security on the partition before the
> operation, and re-establish it on the new partition afterwards.
> ALTER TABLE tp_0_2 DISABLE ROW LEVEL SECURITY;
> ALTER TABLE t SPLIT PARTITION tp_0_2 INTO
> (PARTITION tp_0_1 FOR VALUES FROM (0) TO (1),
> PARTITION tp_1_2 FOR VALUES FROM (1) TO (2)); -- still fails
> ERROR: cannot merge or split partition "tp_0_2" that has row-level
> security policies
> DETAIL: The policies are not carried over to the new partition and
> would be silently lost.
> HINT: Drop the policies from the partition before the operation, and
> define them on the new partition afterwards.
> DROP POLICY hide_secret ON tp_0_2;
> ----------------------------------
> Since we have the MERGE SQL command, it would be better to replace
> "the same reason as MERGE."
> with "the same reason as MERGE PARTITIONS".
>
> I think the HINT in the first error message is not very helpful, it
> suggests disabling row-level security on table tp_0_2.
> However, even if with RLS disabled on table tp_0_2, we still need to
> drop the policies and redefine them.I am OK with the second HINT.
> maybe we can change errhint("Disable row-level security on the
> partition before the operation, and re-establish it on the new
> partition afterwards."));to errhint("Disable row-level security on the
> partition and drop the existing policies before the operation, then
> re-establish them on the new partition afterwards."));

Changed as you proposed.

> "because the row-movement path cannot safely recompute the value while
> re-verifying all of the table's constraints against it."
> I am not sure the word "path" is necessary.
>
> Other than that, v5 looks good to me. (i didn't review 0001 and 0002).
> --------------------
> CREATE ACCESS METHOD partitions_merge_heap TYPE TABLE HANDLER
> heap_tableam_handler;
> begin;
> DROP TABLE if exists t;
> CREATE TABLE t (i int) PARTITION BY RANGE (i);
> CREATE TABLE tp_0_1 PARTITION OF t FOR VALUES FROM (0) TO (1);
> CREATE TABLE tp_1_2 PARTITION OF t FOR VALUES FROM (1) TO (2);
> set local default_table_access_method to partitions_merge_heap;
> ALTER TABLE t MERGE PARTITIONS (tp_0_1, tp_1_2) INTO tp_0_2;
> SELECT a.amname FROM pg_class c, pg_am a WHERE c.relname = 'tp_0_2'
> AND a.oid = c.relam;
> rollback;
>
> The last SELECT query should return "partitions_merge_heap", IIMHO.
> The attached patch based on v5, fixes this issue.

Added as 0005 patch to the patchset.

------
Regards,
Alexander Korotkov
Supabase