Re: Bug in pg_restore with EventTrigger in parallel mode
Fabrízio de Royes Mello <fabriziomello@gmail.com>
From: Fabrízio de Royes Mello <fabriziomello@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: vignesh C <vignesh21@gmail.com>, Michael Paquier <michael@paquier.xyz>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-09T16:56:31Z
Lists: pgsql-hackers
On Mon, Mar 9, 2020 at 12:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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.) > Yeap... you're correct. > 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. > Ok. > 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. > The proposed patch solve the original complain. I was just trying to understand completely what you pointed out before and I agree with you. Thanks for the clear explanation. About the patch LGTM and IMHO we should back-patch it to all supported versions. Regards, -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
Commits
-
Fix pg_dump/pg_restore to restore event triggers later.
- 8728b2c70357 13.0 landed
- fab5456356c2 9.6.18 landed
- f5d49f22653e 11.8 landed
- 4c40b27b5064 12.3 landed
- 475b061c8675 10.13 landed
- 0b02476442d5 9.5.22 landed