| 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Etsuro Fujita | 2026-08-05 12:15:35 | Re: Bug in asynchronous Append |