Re: Parallel INSERT SELECT take 2 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Parallel INSERT SELECT take 2
Date
Msg-id CAA4eK1JjShyk1vFBOjrXV-pbMCF1HnYMNT9bS6JjOKYv9vBOwQ@mail.gmail.com
Whole thread Raw
In response to RE: Parallel INSERT SELECT take 2  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Mon, Apr 26, 2021 at 7:00 AM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> > Instead, how about
> > postgres retries the query upon detecting the error that came from a parallel
> > unsafe function during execution, disable parallelism and run the query? I think
> > this kind of retry query feature can be built outside of the core postgres, but
> > IMO it will be good to have inside (of course configurable). IIRC, the Teradata
> > database has a Query Retry feature.
> >
>
> Thanks for the suggestion.
> The retry query feature sounds like a good idea to me.
> OTOH, it sounds more like an independent feature which parallel select can also benefit from it.
>

+1. I also think retrying a query on an error is not related to this
feature and should be built separately if required.


-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Truncate in synchronous logical replication failed
Next
From: Michael Paquier
Date:
Subject: Re: Table refer leak in logical replication