Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wqp48-002QaO-37 for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Aug 2026 09:34:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wqp47-005AWA-2H for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Aug 2026 09:34:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wqp1Y-0056wr-06 for pgsql-hackers@lists.postgresql.org; Mon, 03 Aug 2026 09:31:56 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wqp1U-00000001g7h-3oUq for pgsql-hackers@postgresql.org; Mon, 03 Aug 2026 09:31:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1785749509; bh=z/rzDz9ONeZTTEM3aJW6roeANJc0nD2PwekBrep69N4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:Message-ID:From; b=jy6832tjJ6yJJKok5nAIyMPUX8tYLewA40/SdiLXK9jlBvJsSTZdvL6+mH+SY1RVH zaww1QtNAAbxwjSPxFwdr2FXMw1v1ur0AY1sVqJdUH3udCVdgtcDLdYhfulUUpBEO3 acBecDZYqFWaap+FsdAju3z9bWGV/rjzg8A+cvc48x0cFBOl8aupmYnkBZMtinsA2W eCMCID9oRaC4lRpx/guIx96yzam1OrMX2CDG4SnEu7zG/VsaoTbukZ2vbD7iNZrwB+ OYOCGLZJeVDZ+IzNjnvngmgkcoMrfzzUic+vrOLZ0kbEMw+cQ7B4N8mOswulexo8hN PQyL3qSsyQOtQ== Received: from mail.l.postgrespro.ru (webmail-master-mstn.l.postgrespro.ru [192.168.2.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.pyhalov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id F0EF1605EC; Mon, 03 Aug 2026 12:31:48 +0300 (MSK) MIME-Version: 1.0 Date: Mon, 03 Aug 2026 12:31:48 +0300 From: Alexander Pyhalov To: Alexander Korotkov Cc: Matheus Alcantara , Pgsql Hackers Subject: Re: Asynchronous MergeAppend In-Reply-To: References: <59be194c5a409fb9fc9f2031581b8a44@postgrespro.ru> <2fb1d9923b6995492e7b163e6cb95402@postgrespro.ru> <782a968c8e01ec6db3b2da2120adf73b@postgrespro.ru> <554a73f7ffea8b22b3f81a4804b5fc34@postgrespro.ru> <42a9a941-e768-4fd8-8067-12958c5a1d70@gmail.com> <10c97af0ce34ebdb81708b1c49ed6038@postgrespro.ru> Message-ID: <96da674ecf493e8ab591b4ce5444ce5d@postgrespro.ru> X-Sender: a.pyhalov@postgrespro.ru Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 3.0.0.9059, bases: 2026/08/03 08:44:00 #28631548 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alexander Korotkov писал(а) 2026-08-03 11:32: > On Mon, Aug 3, 2026 at 8:41 AM Alexander Pyhalov > 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