Re: Asynchronous MergeAppend

Etsuro,
Alexander,

Thank you for making this aspect clear.

On Wed, Aug 5, 2026 at 2:19 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> On Tue, Aug 4, 2026 at 10:32 PM Alexander Pyhalov
> <a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
> > Etsuro Fujita писал(а) 2026-08-03 17:13:
> > > On Mon, Aug 3, 2026 at 3:41 PM Alexander Pyhalov
> > > <a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
> > >> Alexander Korotkov писал(а) 2026-08-01 00:03:
> > >> > On Mon, Jul 6, 2026 at 4:42 PM Alexander Pyhalov
> > >> > <a(dot)pyhalov(at)postgrespro(dot)ru> wrote:
> > >> >> Alexander Korotkov писал(а) 2026-07-04 02:05:
> > >> >>
> > >> >> > While discovering a correctness of callback_pending flag reset in
> > >> >> > async MergeAppend, I found bug in async plain Append [1]. I've
> > >> >> > included the fix as 0001 in the current patchset.
> > >> >>
> > >> >> I expect that this issue can affect both MergeAppend and Append, but
> > >> >> current test cases don't confirm this.
> > >> >> If we revert to the old behavior (setting areq->callback_pending to
> > >> >> false), the tests results of Merge Append tests
> > >> >> are not changed.
> > >> >
> > >> > Did you try the test case showed by Gleb [1]. Yet I think it's safe
> > >> > to follow the fix by Etsuro. In the revised patchset I put this into
> > >> > ExecAppendBaseAsyncProcessPending() and use for both async append and
> > >> > async merge append.
> > >>
> > >> Yes, he found this case when we tested your original fix for
> > >> ExecReScanAppend() behavior.
> > >> I'm fine with following Etsuro's fix.
> > >
> > > Sorry, I renamed that function.
> > >
> > > I haven't looked at the patches yet, sorry, so I'm missing something,
> > > but do we really need the same treatment here? IMU: what async should
> > > be made for in MergeAppend would be only the initialization step that
> > > that node fetches one tuple from every child to seed the heap; other
> > > steps should be processed rather synchronously, to reduce the overhead
> > > by async. So no pending async requests in ExecReScanMergeAppend. No?
> > >
> >
> > Hi. This seems to be true. On the first call to ExecMergeAppend,
> > ExecMergeAppendAsyncGetNext() would get tuples from all valid
> > asyncplans,
> > and so there would be no requests with callback_pending set to true.
> > Subsequent ExecMergeAppendGetNextSlot() also waits for results, so
> > callback_pending should be also false.
>
> Ok, the logic for async execution is pretty complex, so let's avoid
> making the code complicated than necessary.
>
> Thanks for checking!

I've revised (simplified) the patchset according to fact that we can't
have in-flight async requests during the ExecReScanMergeAppend() call.

------
Regards,
Alexander Korotkov
Supabase