Re: Asynchronous MergeAppend

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.

--
Best regards,
Alexander Pyhalov,
Postgres Professional