| 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: | Whole Thread | Raw Message | 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 |