Etsuro Fujita писал(а) 2026-08-03 17:13:
On Mon, Aug 3, 2026 at 3:41 PM Alexander Pyhalov
<[email protected]> wrote:
Alexander Korotkov писал(а) 2026-08-01 00:03:
> On Mon, Jul 6, 2026 at 4:42 PM Alexander Pyhalov
> <[email protected]> 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
