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

Kevin Grittner <kgrittn@gmail.com> writes:
> On Tue, Jul 26, 2016 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's possible that the most reasonable fix is to move matview refreshes to
>> after the ACL restoration step.  That would wreak a lot of havoc with
>> the current view of a dump as being tripartite (pre-data/data/post-data),
>> so it might be more work than we want to do.  But it seems like the
>> logically soundest thing.

> That is exactly what the patch I posted yesterday does.  Peter was
> suggesting that wasn't good enough

Well, he's right: just minimally rearranging the dump order is not enough.
For one thing, I'm pretty sure this patch will fail to fix the bug in a
parallel restore, because restore_toc_entries_parallel has hard-wired
knowledge that ACLs can be done last and serially.  Even if the fix works
in parallel restore, it would result in doing matview refreshes serially
not in parallel, which is a pretty tough nut to swallow.  And I'm not
really convinced that the patch preserves dependency ordering requirements
at all, even in plain serial restore.

The core of the problem here, I think, is that pg_dump has never had any
real notion of dependency ordering for ACLs, since it's always been
sufficient to dump them at the very end in arbitrary order.  If we're now
going to make objects-with-dependencies also dependent on ACLs, I'm afraid
that raises the bar quite a lot in terms of needing to treat ACLs as
real, dependency-sorted objects.

I believe the thrust of Peter's suggestion is to try to avoid biting that
bullet, by instead instituting a rule of "dump an object's ACL immediately
after the object".  But to make this work with the read-only-table
scenario, it would have to be something like "dump an object's GRANTs
immediately after the object, but if there are any self-revokes, dump
those last as we always have".

With either approach, I'm afraid we're talking about a patch much larger
and more invasive than what's here :-(

            regards, tom lane