Re: Asynchronous MergeAppend - Mailing list pgsql-hackers

From Alexander Pyhalov
Subject Re: Asynchronous MergeAppend
Date
Msg-id 96da674ecf493e8ab591b4ce5444ce5d@postgrespro.ru
Whole thread
In response to Asynchronous MergeAppend  (Alexander Pyhalov <a.pyhalov@postgrespro.ru>)
Responses Re: Improve errmsg for publication membership
List pgsql-hackers
Alexander Korotkov писал(а) 2026-08-03 11:32:
> On Mon, Aug 3, 2026 at 8:41 AM Alexander Pyhalov
> <a.pyhalov@postgrespro.ru> wrote:
>> Alexander Korotkov писал(а) 2026-08-01 00:03:
>> > On Mon, Jul 6, 2026 at 4:42 PM Alexander Pyhalov
>> >> 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.
>> >
>> > OK, I changed to this way.
>> 
>> It seems you've missed the attachment.
> 
> Sorry, here it is.
> 
> ------
> Regards,
> Alexander Korotkov
> Supabase


Hi.
We call ExecAppendBaseAsyncProcessPending() in ExecReScanAppend(), but 
timeout depends on node->as_syncdone. Later we still process all async
requests, which have callback_pending set (as we loop until there's no 
requests with callback_pending == false). Should we just set timeout to 
-1 both for Append and MergeAppend to avoid busy loop in 
ExecAppendBaseAsyncProcessPending()? Also it seems strange that timeout 
depends on old (pre-rescan) node->as_syncdone state.

>> 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.

> OK, I changed to this way.

Fine, let's preserve it this way.
-- 
Best regards,
Alexander Pyhalov,
Postgres Professional



Attachment

pgsql-hackers by date:

Previous
From: "chee.wooson"
Date:
Subject: [PATCH v3] Fix exported snapshot xmin handoff race
Next
From: "Yilin Zhang"
Date:
Subject: Re: [PATCH] Add NESTED_STATEMENTS option to EXPLAIN