## Problem The `multixact_size` metric in `config/pgwatch-prometheus/metrics.yml` checks whether `pg_stat_file()` **exists** but not whether the monitoring user has **EXECUTE** privilege on it. On managed PostgreSQL services (e.g. Supabase, some RDS configurations), `pg_stat_file()` exists in the catalog but is restricted to superusers. The `can_local` CTE evaluates to `true`, the `local_probe_xml` branch executes `pg_stat_file()` inside `query_to_xml()`, but `query_to_xml` does not catch permission errors — only missing functions. Result: ``` ERROR: permission denied for function pg_stat_file (SQLSTATE 42501) failed to fetch metric data ``` This error repeats every collection interval. ## Root cause ```sql can_local as ( select (has_pg_ls_dir_func and has_pg_stat_file_func) as ok from env ), ``` This only checks function existence, not permission. ## Fix Add `has_function_privilege()` to the `can_local` CTE: ```sql can_local as ( select (has_pg_ls_dir_func and has_pg_stat_file_func and has_function_privilege('pg_stat_file(text,boolean)', 'execute') ) as ok from env ), ``` When the user lacks permission, `can_local` is `false`, no probe branch matches, and the query falls through to the `status_code = 2` fallback ("not available") — no error, metric reports gracefully. --- ## Acceptance Criteria - `can_local` CTE in `multixact_size` metric includes `has_function_privilege('pg_stat_file(text,boolean)', 'execute')` check - On managed databases where `pg_stat_file()` exists but is restricted to superusers, the metric gracefully falls through to `status_code = 2` ("not available") - No `permission denied for function pg_stat_file` errors in pgwatch logs for managed database connections - On self-hosted databases where the monitoring user has `pg_stat_file()` privilege, the metric continues to work as before ## Definition of Done - Fix applied to the `multixact_size` metric SQL in `config/pgwatch-prometheus/metrics.yml` - Tested against a managed PostgreSQL instance (e.g., Supabase) confirming no permission errors - Tested against a self-hosted instance confirming metrics still collect successfully - No repeated error messages in pgwatch logs for this metric