Re: Bug in pg_restore with EventTrigger in parallel mode

On Fri, Feb 21, 2020 at 12:06 AM Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)com> wrote:
>
>
>
> On Thu, Feb 20, 2020 at 4:52 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >
> > 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.
> >
>
> Indeed... event triggers should be the last thing to be restored.
>
> > 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?
> >
>
> By error I meant the weird behavior I described before that pg_restore create the event triggers in parallel mode and after that other objects are created then the event trigger is fired during the restore...
>
> Have a look at the new attached patch.
>

The test works fine with the patch.

Few comments:
There is minor code alignment that need to be fixed:
git apply fix_pg_restore_parallel_with_event_trigger_v2.patch
fix_pg_restore_parallel_with_event_trigger_v2.patch:11: trailing whitespace.
* then ACLs, matview refresh items, then event triggers. We might be
warning: 1 line adds whitespace errors.

I'm not sure if we can add a test for this, can you have a thought
about this to check if we can add a test.

Regards,
Vignesh
EnterpriseDB: http://www.enterprisedb.com