would love this feature for temporary troubleshooting

Would also love to be able to use this for troubleshooting. We've got a very difficult problem taking our whole instance down at random. There's not enough information in the logs for us to diagnose. We don't use pgsodium or vault so we're not concerned about leaking any encrypted data to logs.

If you're self-hosting, you should be able to modify it by connecting assupabase_admin

Worked, thanks! What's the technical explanation for this? Even with the postgres role, I got no permission error, and the setting was persistent across sessions and restarts globally:

SELECT     r.rolname                                           AS role_name,    COALESCE(d.datname, 'GLOBAL')                       AS scope,    unnest(COALESCE(s.setconfig, r.rolconfig))          AS raw_setting,    regexp_match(unnest(COALESCE(s.setconfig, r.rolconfig)), '^pgaudit\.([^=]+)=(.*)') AS parsedFROM pg_roles rLEFT JOIN pg_db_role_setting s ON s.setrole = r.oidLEFT JOIN pg_database d        ON d.oid = s.setdatabaseWHERE (r.rolconfig::text ILIKE '%pgaudit%'     OR s.setconfig::text   ILIKE '%pgaudit%')ORDER BY role_name, scope;

→ looks exactly the same after regardless of whether I set it with postgres or supabase_admin

Ah, I assumed from your original comment that you tried running it aspostgres but it didn't work. It actually should work that way on the hosted platform, but hadn't tested it on the self-hosted setup.

Correction:pgaudit.log_parameter isn't configurable on the hosted platform either. I think it works on the self-hosted platform becausepostgres is a superuser there, so it won't hit permission errors

Yes, but it does show the parameters now after setting it with supabase_admin. Maybe some overnight replication magic happened, but I restarted multiple times after setting it with postgres and it continuously showed,<not logged> in the audit logs normal forlog_parameter=off (which were'on' though) up until setting it with supabase_admin