Re: Asynchronous MergeAppend

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?

I was planning to review the patches in the July CF, but
unfortunately, I didn't have time for that, so I'd like to review them
in the September CF at top priority. Is that possible? Anyway,
thanks for working on this, everyone!

Best regards,
Etsuro Fujita