Re: Bug in pg_restore with EventTrigger in parallel mode - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in pg_restore with EventTrigger in parallel mode
Date
Msg-id 11753.1583767625@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in pg_restore with EventTrigger in parallel mode  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Responses Re: Bug in pg_restore with EventTrigger in parallel mode  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
List pgsql-hackers
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabriziomello@gmail.com> writes:
> On Sat, Mar 7, 2020 at 8:42 PM Tom Lane <tgl@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



pgsql-hackers by date:

Previous
From: Kuntal Ghosh
Date:
Subject: Re: backend type in log_line_prefix?
Next
From: Alvaro Herrera
Date:
Subject: Re: pgsql: pageinspect: Fix types used for bt_metap() columns.