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.
Best regards,
Etsuro Fujita