Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view
| От | Maxim Boguk |
|---|---|
| Тема | Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view |
| Дата | |
| Msg-id | CAK-MWwQBrjfAPu=nfWS9B_Y5QK147xU2Y-EpDYAvsrdni97HCw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: BUG #18387: Erroneous permission checks and/or misleading error messages with refresh materialized view
|
| Список | pgsql-bugs |
> 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).
Maxim Boguk
Senior Postgresql DBA
Phone UA: +380 99 143 0000
Phone AU: +61 45 218 5678
Senior Postgresql DBA
Phone UA: +380 99 143 0000
Phone AU: +61 45 218 5678
В списке pgsql-bugs по дате отправления: