On Mon, Mar 9, 2020 at 3:59 PM Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > On Mon, Mar 9, 2020 at 12:27 PM Tom Lane wrote:
> >> Which, TBH, makes me wonder about the validity of the original
complaint
> >> in this thread. I don't mind delaying ET restore as long as
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> On Mon, Mar 9, 2020 at 12:27 PM Tom Lane wrote:
>> Which, TBH, makes me wonder about the validity of the original complaint
>> in this thread. I don't mind delaying ET restore as long as we feasibly
>> can; but if you have an ET that is going to
On Mon, Mar 9, 2020 at 12:27 PM Tom Lane wrote:
>
> In the case of event triggers, the obvious counterexample is that if
> you restore ET A and then ET B, ET A might interfere with the attempt
> to restore ET B. (And we have no way to know whether restoring B
> before A would be better or worse.)
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> On Sat, Mar 7, 2020 at 8:42 PM Tom Lane wrote:
>> However, I think that the existing code is correct to restore event
>> triggers before matview refreshes, not after as this patch would have us
>> do. The basic idea for matview refresh is that i
On Sat, Mar 7, 2020 at 8:42 PM Tom Lane wrote:
>
> vignesh C writes:
> > 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.
>
> Yeah, I'm not quite sure if a test is worth the trouble or not.
>
> We clearly do need to restore event tri
vignesh C writes:
> 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.
Yeah, I'm not quite sure if a test is worth the trouble or not.
We clearly do need to restore event triggers later than we do now, even
without considering parallel
On Fri, Feb 21, 2020 at 12:06 AM Fabrízio de Royes Mello
wrote:
>
>
>
> On Thu, Feb 20, 2020 at 4:52 AM Michael Paquier 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 hi
On Thu, Feb 20, 2020 at 4:52 AM Michael Paquier 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
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
> everyth
On Thu, Feb 13, 2020 at 12:52 AM Michael Paquier
wrote:
> 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 pend
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
> everyth
Hi all,
Today digging into a customer issue about errors in pg_restore I realized
that pg_restore dispatch a worker to restore EventTrigger
during restore_toc_entries_parallel. IMHO EventTriggers should be restored
during the restore_toc_entries_postfork in serial mode.
For example this simple da
12 matches
Mail list logo
