Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance

> On Fri, Dec 31, 2021 at 04:36:42PM +0900, Etsuro Fujita wrote:
> On Tue, Dec 28, 2021 at 10:14 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > The root cause of the
> > assertion failure in the first case might be something other than the
> > limitation.  I’ll look into this in more detail.
>
> I think the root cause is that we fail to process a pending async
> request (if any) in postgresReScanForeignScan() in the case where we
> just reset the next_tuple counter in that function, without
> destroying/recreating or rewinding the cursor.  (In the case where we
> destroy/recreate or rewind the cursor in that function, the pending
> async request would be processed by pgfdw_exec_query() called from
> that function.)  This breaks the assumption about ExecAppend() that
> when called for the first time after ReScan, there are no pending
> async requests made for async subplans for the Append node, causing
> the assertion failure in postgresForeignAsyncRequest() called from
> that ExecAppend().  My oversight in commit 27e1f1456.  :-(
>
> To fix, I modified postgresReScanForeignScan() so that we always
> process a pending async request (if any) before restarting the foreign
> scan.  Attached is a patch for that.  I tested the patch with the
> first case, and it addresses the assertion failure.

Yep, makes sense now, thank you. The fix works for me, but I'm curious
about the requestee condition:

    fsstate->conn_state->pendingAreq->requestee == (PlanState *) node)

You've mentioned that in those cases where the cursor will be
destroyed/recreated or rewind, pgfdw_exec_query will take care of
processing pending requests, and looks like it will do this without
checking the requestee. Just for me to understand, why is this condition
necessary?