From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in pg_restore with EventTrigger in parallel mode |
Date: | 2020-02-20 07:52:32 |
Message-ID: | 20200220075232.GN2288@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-02-20 08:14:37 | Re: allow running parts of src/tools/msvc/ under not Windows |
Previous Message | Amit Langote | 2020-02-20 07:50:50 | Re: Autovacuum on partitioned table |