At 2026-05-10 14:23:26, "jian he" <[email protected]> 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 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
