Re: Inherited UPDATE/DELETE vs async execution

On Wed, May 12, 2021 at 6:45 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Tue, May 11, 2021 at 9:53 PM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> > Okay, so I take it that making these ForeignScan nodes (that only
> > fetch the data) asynchronous doesn't interfere with update/delete
> > subsequently being performed over presumably the same connection to
> > the remote server.
>
> Good point! I don't think it would interfere with the update/delete,
> because in that case postgres_fdw would actually perform the
> update/delete and the asynchronous foreign scans serially rather than
> concurrently. (They wouldn't be perfomed in parallel unless they use
> different connections, in other words.)

I see, that makes sense.

> > > > Or the other way around --
> > > > is it because fixing the crash that occurs in the former's case would
> > > > be a significant undertaking for little gain?
> > >
> > > Yeah, I think it would be a good idea to support "Async Foreign
> > > Delete" in the former's case. And actually, I tried to do so, but I
> > > didn't, because it seemed to take time.
> >
> > Ah I see. I guess it makes sense to prevent such cases in v14 as your
> > patch does, and revisit this in the future.
>
> +1
>
> Here is a rebased version of the patch. I'm planning to apply this tommorow.

+ /*
+ * Finally, unset the async-capable flag if it is set.
+ */

Would it make sense to expand here even just a bit on why we must do this?

--
Amit Langote
EDB: http://www.enterprisedb.com