Re: Bug in pg_restore with EventTrigger in parallel mode

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug in pg_restore with EventTrigger in parallel mode
Дата
Msg-id 11753.1583767625@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bug in pg_restore with EventTrigger in parallel mode  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Ответы Re: Bug in pg_restore with EventTrigger in parallel mode  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kuntal Ghosh
Дата:
Сообщение: Re: backend type in log_line_prefix?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: pageinspect: Fix types used for bt_metap() columns.