Hi, On Tue, Aug 4, 2026 at 9:20 PM Gleb Kashkin <[email protected]> wrote: > > Hi. It seems there is the last small issue with the patch. > > > > The following scenario is possible: > > > > 1) During rescan, one child of the Append has already produced a tuple > > and set as_needrequest > > 2) Another child still has callback_pending, but its postgres_fdw > > connection is occupied by an async request belonging to a different > > Append > > 3) While draining the second child, postgresForeignAsyncConfigureWait() > > sees the different requestor and the stale nonempty as_needrequest, so > > it returns without registering an event > > 4) The reset loop then repeats without making progress > > > > See reproducer and fix in the patch. It should be applied to v2. > Sorry, misclicked. Here is the patch.
Good catch! I think that the scenario is possible, and the fix is correct. I couldn't reproduce it in my environment, though. I think it probably depends on the environment. I don't want to further increase the elapsed time for the postgres_fdw regression test, for this rather-minor case, so sorry, I incorporated only the fix, then added asserts and tweaked the comment a bit. Attached is a new version of the patch. Thanks for the feedback and patch! Best regards, Etsuro Fujita
Fix-bug-in-async-append-efujita-v3.patch
Description: Binary data
