Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
От | Etsuro Fujita |
---|---|
Тема | Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance |
Дата | |
Msg-id | CAPmGK16n1VHbJHTRdrJ3vS8ZEv2vkFsNT_mf00kKffS04uctMw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance (Etsuro Fujita <etsuro.fujita@gmail.com>) |
Ответы |
Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance
Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance |
Список | pgsql-bugs |
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
Вложения
В списке pgsql-bugs по дате отправления: