Peter Eisentraut <pe...@eisentraut.org> writes: > On 07.02.24 16:26, Tom Lane wrote: >> Why would a test be applying pg_get_expr to a table it doesn't >> control?
> I think the situation is that one test (domain) runs pg_get_expr as part > of an information_schema view, while at the same time another test > (alter_table) drops a table that the pg_get_expr is just processing. The test case that's failing is, IIUC, +SELECT * FROM information_schema.domain_constraints + WHERE domain_name IN ('con', 'dom', 'pos_int', 'things') + ORDER BY constraint_name; I see no use of pg_get_expr() in the domain_constraints view: CREATE VIEW domain_constraints AS SELECT CAST(current_database() AS sql_identifier) AS constraint_catalog, CAST(rs.nspname AS sql_identifier) AS constraint_schema, CAST(con.conname AS sql_identifier) AS constraint_name, CAST(current_database() AS sql_identifier) AS domain_catalog, CAST(n.nspname AS sql_identifier) AS domain_schema, CAST(t.typname AS sql_identifier) AS domain_name, CAST(CASE WHEN condeferrable THEN 'YES' ELSE 'NO' END AS yes_or_no) AS is_deferrable, CAST(CASE WHEN condeferred THEN 'YES' ELSE 'NO' END AS yes_or_no) AS initially_deferred FROM pg_namespace rs, pg_namespace n, pg_constraint con, pg_type t WHERE rs.oid = con.connamespace AND n.oid = t.typnamespace AND t.oid = con.contypid AND (pg_has_role(t.typowner, 'USAGE') OR has_type_privilege(t.oid, 'USAGE')); I'm a little suspicious that the failure is actually coming from somewhere down inside has_type_privilege(), but I traced through that quickly and don't see how it could reach such an error. In any case I thought we'd hardened all those functions in 403ac226d. So I'm still pretty mystified. Have you had any luck in making the failure reproducible? regards, tom lane