[OffgridwithJD]

Part of #1341: the three High rollup privilege items (two entries each, from the sql-objects and time-series searches). Every arm is in both twins. Each is red under a mutation of pgcolumnar--1.0-alpha5.sql that main survives.

What the code does

Checked in the code before writing any arm:

• No leak in the definer helpers. rollup_source_groups and rollup_source_retired are SECURITY DEFINER with PUBLIC EXECUTE, but both first call require_caller_select. That checks pg_class_aclcheck(..., GetOuterUserId(), ACL_SELECT), the role outside the definer switch. So this is a missing arm, not a missing fix.
• The catalogs' policies have USING only. With no WITH CHECK, USING also checks an INSERT's new row. An UPDATE or DELETE with no WHERE reads no column, so only USING keeps it off another owner's rows. The arms use exactly that unqualified form.

Arms and mutations

PG17, both twins, main e848f8f (#1354 merged) against this branch:

arm	mutation	main	this branch
another role cannot read the source's groups through rollup_source_groups (42501)	the helper's PERFORM require_caller_select deleted	sh 72/72, py passed	"got [] want [42501]"; py "got '1'"
nor its retired groups through rollup_source_retired (42501)	the same, in the other helper	green	"got [] want [42501]"; py "got '0'"
another role cannot add a group row to the owner's rollup (42501)	both policies given WITH CHECK (true)	green	"got [] want [42501]"; the write arm also sees the inserted row: f|2
and its unqualified UPDATE and DELETE reach none of the owner's catalog rows	a permissive FOR UPDATE and FOR DELETE policy USING (true)	green	"got [t|0] want [f|1]"

There are two never rows:

• the owner's own call through both helpers, which shows the definer path works for the role it's meant for;
• a premise that the owner's rollup has group rows to protect.

In pytest, the write arms come before the existing read-side arms. Its hard asserts stop at the first failure, so a write that gets through is what's reported.

Evidence

• Clean: rollup 78/78 and test_rollup.py passed on each of PG 15–19.
• Ledger: six rows, four dated and two never: 2336 → 2342, census 1803 → 1805.
• Gate: --against origin/main (8af86e8) gives rc=0 with the census agreeing; the ceiling stays 246 → 246.
• Database-free set: 429 passed. No test functions were added.

🤖 Generated with Claude Code

[jdatcmd]

Approving the content at 1e42343. On PG17 I reproduced the write-side claim by giving both catalog policies WITH CHECK (true):

• main: rollup passes 72/72.
• this head: "another role cannot add a group row to the owner's rollup (42501): got [] want [42501]", and the write arm reports f|2, as you describe.

I agree with your reading of the helpers: require_caller_select checks GetOuterUserId(), so they need arms, not a fix.

Needs a rebase before merge. Main is now 1933577 at 2343 / 1796 (#1353 and #1355 merged). With your six rows (four dated) I expect 2349 / 1798. Rebase and restate from a recount, and I'll check the ledger and merge.

[OffgridwithJD]

@jdatcmd, rebased onto 1933577. The new head is f90200f, replacing 1e42343. Ledger: 2349 / 1798 (2343 + 6 rows; never 1796 + 2).

• Conflict: only check_ledger_budget.txt, restated on top of test: ttl_expire's twins ask the same question: expire's return on a date column, the no-retention SQLSTATE (#1339) #1355's block. The tsv merged cleanly, with no duplicate keys.
• Patch unchanged: outside the budget, the changed lines match 1e42343 exactly.
• Evidence still applies: since the evidence base (e848f8f), main has changed no src/ or SQL file and neither rollup test file, so rollup 78/78 on 15–19 and the four mutant results stand.
• Checks: the gate gives rc=0 with the census agreeing at 1798, and the database-free set gives 429 passed. I'll ping on green CI.

[jdatcmd]

Re-approving f90200f.

• Ledger: a recount gives 2349 / 1798, which agrees with the budget. No duplicate keys, no dated premise: row.
• Patch: the rollup changes are identical to 1e42343, the head I reviewed and reproduced (52 lines).
• Database-free set: 429 passed.

Merging.