Subject: Re: COPY FROM with RLS

From: solai v <[email-masked]>
Date: Mon, 25 May 2026 10:20:37 +0530

Hi jian,
I tested the v2 patch for COPY FROM with RLS.
Before applying the patch, I was able to reproduce the issue where
\copy bypassed the RLS INSERT policy and allowed invalid rows to be
inserted.
After applying the patch and retesting, rows violating the policy were
correctly rejected during \copy, while valid rows were inserted
successfully. The behavior is now consistent with normal INSERT.
The error context reporting during COPY was also clear and helpful
while testing.

Regards,
Solai

---

From: "Yilin Zhang" <[email-masked]>
Date: Mon, 29 Jun 2026 18:13:02 +0800 (CST)

At 2026-05-10 14:23:26, "jian he" <[email-masked]> wrote:
>Hi. I implemented a hack to make it work with RLS policies that
>contain subqueries; I'm not sure how valid it is.
>
>IF  (check_enable_rls(RelationGetRelid(cstate->rel), InvalidOid,
>false) == RLS_ENABLED)
>is true, then we construct a dummy query string:
>
>INSERT INTO "%s"."%s" DEFAULT VALUES
>
>(where %s.%s is replaced by the schema-qualified relation name) and
>then run it through the following pipeline:
>pg_analyze_and_rewrite_fixedparams()
>pg_plan_query()
>CreateQueryDesc()
>ExecutorStart()
>
>Obviously, ExecutorRun() cannot be used because the data source for COPY FROM is
>an external file rather than a normal query execution.
>
>The main hack is to bypass ExecutorRun() completely and only use ExecutorStart()
>to initialize the required executor structures (EState, PlanState,
>ResultRelInfo, etc.) for ExecWithCheckOptions (which is part of
>ExecutorRun normally).
>
>In DoCopy we did converting COPY (REL) TO,to a SelectStmt  when REL have RLS.

Hi, I've gone through your v2 patch and there’s an issue I’d like to point out.
In src/test/regress/expected/rowsecurity.out:

+-- COPY FROM should also apply INSERT CHECK policy clause
+COPY rls_test_tgt FROM STDIN WITH (DELIMITER ',');
+ERROR:  missing data for column "c"
+CONTEXT:  COPY rls_test_tgt, line 1: "1,tgt a"

This "missing data for column c" error is actually a COPY formatting error, not an RLS policy violation.

Best regards,

--

Yilin Zhang

---

From: "Yilin Zhang" <[email-masked]>
Date: Tue, 30 Jun 2026 09:20:20 +0800 (CST)

>In DoCopy we did converting COPY (REL) TO,to a SelectStmt  when REL have RLS.

Hi, I found another issue with the v2 patch.
When running COPY FROM against a partitioned table with RLS enabled, ExecSetupPartitionTupleRouting gets invoked twice, 
which creates two separate sets of PartitionTupleRouting structures.
One of these sets never gets cleaned up, and PostgreSQL’s ResourceOwner mechanism catches this and emits the following warnings:

  WARNING:  resource was not closed: relation "rls_part_1"
  WARNING:  resource was not closed: relation "rls_part_2"

Best regards,

--

Yilin Zhang