Re: BUG #13907: Restore materialized view throw permission denied

On Mon, Jul 25, 2016 at 8:37 PM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 7/25/16 4:09 PM, Kevin Grittner wrote:
>> On Mon, Jun 27, 2016 at 1:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> I'm planning to apply the attached revision as soon as I get done
>>> back-porting it.
>>
>> I'm thinking of applying something like the attached to fix the
>> rest of this bug.
>
> The reason that ACLs are restored last is that they could contain owner
> self-revokes. So anything that you run after the ACLs could fail
> because of that. I think a more complete fix would be to split up the
> ACL restores into the general part, which you would run right after the
> object is restored, and the owner revokes, which you would run last.

So you are suggesting that restoring from pg_dump output should
generate materialized view data under a different security context
than would be used by a REFRESH statement on the source database?

Anything you can add to clarify what you mean by "owner
self-revokes" and why the security should be different when the
matview data is refreshed at the end of the restore should be
different from what would happen on the database which was backed
up might be helpful.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company