Re: Asynchronous MergeAppend

From: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
To: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Asynchronous MergeAppend
Date: 2026-08-05 12:18:58
Message-ID: CAPmGK17tsf5zm5EeXaJipak1K4K=5hsfRD3D5HFBpu+cpb+7vw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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!

Best regards,
Etsuro Fujita

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Etsuro Fujita 2026-08-05 12:15:35 Re: Bug in asynchronous Append