Re: Asynchronous MergeAppend
Alexander Pyhalov <a.pyhalov@postgrespro.ru>
From: Alexander Pyhalov <a.pyhalov@postgrespro.ru>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>, Pgsql Hackers
<pgsql-hackers@postgresql.org>
Date: 2026-07-06T14:42:42Z
Lists: pgsql-hackers
Hi. 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. Other changes to > patchset includes. > 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. > 0003 contains some cleanups > * Unify set_append_references and set_mergeappend_references > (setrefs.c) > * Merge duplicate Append/MergeAppend cases in explain.c > * Merge duplicate Append/MergeAppend cases in > planstate_tree_walker_impl (nodeFuncs.c) This looks good. > 0006 includes following optimizations and fixes > * Fix assertion failure on MergeAppend rescan with an in-flight async > request (same as 0001 but for MergeAppend) > * Don't use ExecProcNode() for async subplans. Despite its > effectiveness, it doesn't works correctly. When postgres_fdw subplan > is executed by ExecProcNode() it interprets the end of async batch as > end of the whole data. That effectively leads to skipping the > remaining dataset after first batch (100 rows). The test is added. Ouch. Luckily we've catched this. postgresIterateForeignScan() doesn't fetch tuples for async scan states... > * Make ExecReScanMergeAppend() clear ms_slots. Otherwise subsequent > scans can use leftover tuples. The test is also added. This seems to happen only in updated version of the patch, where ExecMergeAppendAsyncGetNext() relies on the fact that async requests have been already sent (previously this function firstly set slot to NULL prior to sending requests and processing them). > * Document that the needrequest fast-skip is a no-op for MergeAppend > (postgres_fdw.c) > * Document why create_merge_append_plan discards > mark_async_capable_plan's result (createplan.c) > Looks good. ExecMergeAppendGetNextSlot() - I'd sligtly prefer to check if mplan is member of as_asyncplans and assert that it's a member of node->as.valid_asyncplans in this case, but I think it doesn't matter much. -- Best regards, Alexander Pyhalov, Postgres Professional
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Handle interrupts while waiting on Append's async subplans
- af717317a04f 18.0 cited