On Wed, Aug 19, 2026 at 7:58 PM Alexander Korotkov <aekorotkov@gmail.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."));
"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.
--
jian
https://www.enterprisedb.com/
