Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Instead, I've prepared the attached draft patch, which addresses the
>> problem by teaching pg_backup_archiver.c to process TOC entries in
>> three separate passes, "main" then ACLs then matview refreshes.
> What worries me a bit is the possibility that something might depend
> on a matview having already been refreshed. I cannot immediately
> think of a case whether such a thing happens that you won't dismiss as
> wrong-headed, but how sure are we that none such will arise?
Um, there are already precisely zero guarantees about that. pg_dump
has always been free to order these actions in any way that satisfies
the dependencies it knows about.
It's certainly possible to break it by introducing hidden dependencies
within CHECK conditions. But that's always been true, with or without
materialized views, and we've always dismissed complaints about it with
"sorry, we won't support that". (I don't think the trigger case is
such a problem, because we restore data before creating any triggers.)
Meanwhile, we have problems that bite people who aren't doing anything
stranger than having a matview owned by a non-superuser. How do you
propose to fix that without reordering pg_dump's actions?
Lastly, the proposed patch has the advantage that it acts at the restore
stage, not when a dump is being prepared. Since it isn't affecting what
goes into dump archives, it doesn't tie our hands if we think of some
better idea later.
regards, tom lane
