| From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, marian(dot)krucina(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #13907: Restore materialized view throw permission denied |
| Date: | 2016-07-26 17:44:15 |
| Message-ID: | CACjxUsPu8uNHYvTtUa9v3k6nOnG+w7cc4Kr2xVagB5cUEbfBDQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Tue, Jul 26, 2016 at 12:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 and that we should "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." I guess the idea is that we would refresh the matviews in
between those two phases.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-07-26 18:30:06 | Re: BUG #13907: Restore materialized view throw permission denied |
| Previous Message | Tom Lane | 2016-07-26 17:32:47 | Re: BUG #13907: Restore materialized view throw permission denied |