From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Etsuro Fujita <etsuro.fujita@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Cc: exclusion@gmail.com
Subject: Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
Date: Fri, 31 Dec 2021 13:32:11 +0100
Message-ID: <20211231123211.dnohvu5exp5dr5oe@erthalion.local> (raw)
In-Reply-To: <CAPmGK16n1VHbJHTRdrJ3vS8ZEv2vkFsNT_mf00kKffS04uctMw@mail.gmail.com>
References: <17344-226b78b00de73a7e@postgresql.org>
<20211225232625.5xuplnlegneh42cw@erthalion.local>
<CAPmGK15F_oKapcDmrBeRD5bOiyTPhN+8UPPz6r0ANKwGei3hsQ@mail.gmail.com>
<CAPmGK16n1VHbJHTRdrJ3vS8ZEv2vkFsNT_mf00kKffS04uctMw@mail.gmail.com>
> 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?
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: 9erthalion6@gmail.com, etsuro.fujita@gmail.com, pgsql-bugs@lists.postgresql.org, exclusion@gmail.com
Subject: Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
In-Reply-To: <20211231123211.dnohvu5exp5dr5oe@erthalion.local>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox