> test=# REFRESH MATERIALIZED VIEW CONCURRENTLY test_mv; > ERROR: permission denied for table test > --what??? N1 > > --check that im not hallucinating > test=# select * from test; > val > ----- > 1 > (1 row)
So far, this is working correctly. REFRESH MATERIALIZED VIEW runs with the permissions of the materialized view's owner. In this case, the owner is 'test_role', which doesn't have select permission on the table.
This decision led to a strange (and only one known to me) case when a superuser cannot do something in the database.
(so far I have yet to see any other possible scenario when a command run by superuser fails with permission error).
May I suggest a change to always allow superuser run REFRESH MATERIALIZED VIEW (may be via set role or similar mechanics)?
Without that I think it's possible build a case of the database which could be dumped but cannot be restored without errors
(restore from MV owner cannot be done because dump contains create extension (for a sample) and restore from superuser cannot be done because refresh MV permission check).