Re: Bug in pg_restore with EventTrigger in parallel mode
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Fabrízio de Royes Mello <fabriziomello@gmail.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2020-02-20T07:52:32Z
Lists: pgsql-hackers
On Wed, Feb 12, 2020 at 01:59:05PM -0300, Fabrízio de Royes Mello wrote: > In parallel mode it's firing the EventTrigger and it can't be happen. > Poking around it I did some test with attached just to leave EventTriggers > in pending_list to process it in restore_toc_entries_postfork and > everything is ok, but my solution is very ugly, so maybe we need to invent > a new RestorePass to take care of it like RESTORE_PASS_ACL and > RESTORE_PASS_REFRESH. I can provide a more polished patch if it'll be a > good way to do that. That sounds right, as event triggers could interact with GRANT and REFRESH of matviews, so they should be logically last. Looking at the recent commit history, this would be similar to 3eb9a5e as we don't really have a way to treat event triggers as dependency-sortable objects. What kind of errors did you see in this customer environment? Errors triggered by one or more event triggers blocking some commands based on a tag match? -- Michael
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