=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziome...@gmail.com> writes: > On Sat, Mar 7, 2020 at 8:42 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> However, I think that the existing code is correct to restore event >> triggers before matview refreshes, not after as this patch would have us >> do. The basic idea for matview refresh is that it should happen in the >> normal running state of the database. If an event trigger interferes with >> that, it would've done so in normal running as well.
> I'm not totally sure if it's entirely correct. > For example if I write an EventTrigger to perform some kind of DDL auditing > then during the restore the "refresh maview" operation will be audited and > IMHO it's wrong. The big problem I've got with this line of reasoning is that not everything can be the last restore step. There was already an argument that matviews should be refreshed last so they can see the final state of the catalogs, in case you have a matview over some catalog (and of course that applies to pg_event_trigger as much as any other catalog). Admittedly, that seems like an unlikely use-case, but it demonstrates that there are limits to how much we can guarantee about dump/restore producing just the same state that prevailed before the dump. In the case of event triggers, the obvious counterexample is that if you restore ET A and then ET B, ET A might interfere with the attempt to restore ET B. (And we have no way to know whether restoring B before A would be better or worse.) So on the whole I find "restore matviews as if they'd been refreshed after the restore" to be a more trustworthy approach than the other way. At some level we have to trust that ETs aren't going to totally bollix the restore. Which, TBH, makes me wonder about the validity of the original complaint in this thread. I don't mind delaying ET restore as long as we feasibly can; but if you have an ET that is going to misbehave during restore, you are in for pain, and it's hard to consider that that pain isn't self-inflicted. regards, tom lane