PostgreSQL 19 ON CONFLICT DO SELECT can leak security_barrier rows

PostgreSQL 19’s new ON CONFLICT DO SELECT path lets a user who holds only INSERT and SELECT on a security_barrier view read base-table rows the view is supposed to hide.

Shihao Zhong reported the exposure on pgsql-hackers. Before 19, reaching a conflicting row through a view required DO UPDATE, which needs UPDATE privilege. DO SELECT needs only SELECT, so a grant that once stopped short of hidden data no longer does. In Zhong’s example, a view limited to the current user’s documents, granted to alice for insert and select, still returns bob’s salary row when alice inserts a conflicting key with ON CONFLICT DO SELECT … RETURNING. Pairing that with a generated key list and a rollback can walk the whole underlying table. WITH CHECK OPTION does not block the read because nothing is written. Row-level security is already safe: the executor checks the existing row against SELECT policies. Security-barrier views do not get the same check today.

Documentation already notes that DO SELECT needs only SELECT and that ON CONFLICT can touch a row invisible through the view, but it never states that the hidden row is returned to the client, and the security_barrier material does not mention ON CONFLICT.

Zhong floated two fixes: document the behavior plainly, or reject DO SELECT when the existing row fails the view’s quals (as RLS does), and asked whether the harder fix should be a 19 open item. Kirill Reshke called returning previously unretrievable rows a regression that needs both a fix and an open item. Zsolt Parragi argued the report belonged on the security list instead; Reshke replied that an unreleased version is fair game on hackers.

No final decision is recorded in the exchange. The practical stake is clear for anyone shipping security_barrier views as an access boundary in 19: INSERT and SELECT alone may be enough to exfiltrate rows the view was built to conceal.