Re: Bug in pg_restore with EventTrigger in parallel mode

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

In response to

Responses

Browse pgsql-hackers by date

  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