On Wed, May 12, 2021 at 6:45 PM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: > On Tue, May 11, 2021 at 9:53 PM Amit Langote <amitlangot...@gmail.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
