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 |
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 |