Date: Fri, 31 Dec 2021 13:32:11 +0100
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, exclusion@gmail.com
Subject: Re: BUG #17344: Assert failed on queiring async_capable foreign
 table with inheritance
Message-ID: <20211231123211.dnohvu5exp5dr5oe@erthalion.local>
References: <17344-226b78b00de73a7e@postgresql.org>
 <20211225232625.5xuplnlegneh42cw@erthalion.local>
 <CAPmGK15F_oKapcDmrBeRD5bOiyTPhN+8UPPz6r0ANKwGei3hsQ@mail.gmail.com>
 <CAPmGK16n1VHbJHTRdrJ3vS8ZEv2vkFsNT_mf00kKffS04uctMw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAPmGK16n1VHbJHTRdrJ3vS8ZEv2vkFsNT_mf00kKffS04uctMw@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20211231123211.dnohvu5exp5dr5oe%40erthalion.local>
Precedence: bulk

> 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?