Re: Bug in pg_restore with EventTrigger in parallel mode

From: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in pg_restore with EventTrigger in parallel mode
Date: 2020-02-20 18:36:01
Message-ID: CAFcNs+rPSoZ+kcdC7PqmDqurj4nPLEtc-vyRZ_krU+Ac++4PyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Regards,

--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Attachment Content-Type Size
fix_pg_restore_parallel_with_event_trigger_v2.patch text/x-patch 2.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-02-20 18:40:47 Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Previous Message Tom Lane 2020-02-20 18:10:26 Re: error context for vacuum to include block number