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 1vJHbh-00HNPm-2M for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Nov 2025 20:38:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vJHbf-00ENY2-1W for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Nov 2025 20:38:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vJHbe-00ENXt-2P for pgsql-hackers@lists.postgresql.org; Wed, 12 Nov 2025 20:38:19 +0000 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vJHbb-007POT-2Z for pgsql-hackers@postgresql.org; Wed, 12 Nov 2025 20:38:18 +0000 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.stl.internal (Postfix) with ESMTP id A02821D00172; Wed, 12 Nov 2025 15:38:12 -0500 (EST) Received: from phl-imap-03 ([10.202.2.93]) by phl-compute-05.internal (MEProxy); Wed, 12 Nov 2025 15:38:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=compiler.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1762979892; x=1763066292; bh=1713Mra7VmICo5qVjM3drK1CAo+w7r1BQO3mfsB+9Eo=; b= RCc5p3Q9rK1PQeu2t2TM6OzdxExEVXSD+XuDZubUiXHJa47xyiqq5rPEOb4fK2Be ilzb2vjy9PICIKdbZQYj8m2WVxrts/cfdQAoXviuJcjvyUhaVF7Nez5aidztq+TW KitzOeGFSs0uNwndTaNPu9I9vUalQVxxkMG2/zxiM01PF/S3p5h/eR0Qw1eIkZc0 aVN5b0+dLIUdGJWPE5gXA3p5pHt/9Q/J4XqYMZUYDWgmp9xo6ed+RbkEM7ACmAlr 9g7kPTD7QJ4j8TsXBk3LyEfNUV8lcUy12rVODswzmZxZxQgtzOyaf9e7M4R8xssX jUPXYTSE7y/2nWFddtXc1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1762979892; x= 1763066292; bh=1713Mra7VmICo5qVjM3drK1CAo+w7r1BQO3mfsB+9Eo=; b=Q gA6JgWj1CNdcskCerne0jntjs5XBpLFgm76qIR6i+WomQzDvDWYmbOPEtwQfOsLz WGQNgaaijxe91HgBmRmFgNtZDzSYKfGDv/Sly3LGw31VJIWYBu6ZAs9LlhGoqoUA uHfAFkkFVYGSGbUQEL6Js/DXSQMUuQYOWDwQv33HfWyGDKCvWJn5vjH75Ve/WNTT uqwSwM3pOcD+q+YgHe2Qf2eXzVsaP7ZDA2WvDRv131DkT1V1YKlbSTbh/GiHxYgN dlqASTz5v7fZTwVZLG2l90KcWFY5CubZqOnXLDtupdWfr6odmZCtqmTX1XguA5UQ iNXD+7OuCTUJuW3ECGfhw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvtdehtdehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvvefkjghfufgtgfesthhqre dtredtjeenucfhrhhomhepfdflohgvlhculfgrtghosghsohhnfdcuoehjohgvlhestgho mhhpihhlvghrrdhorhhgqeenucggtffrrghtthgvrhhnpefggfeuheefheeufeegkeeife ffhffgvefftdduuefhfeelteegleehhfdtieevgfenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgvlhestghomhhpihhlvghrrdhorhhgpd hnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrrhhs vghnihihrdhmuhhkhhhinhdruggvvhesghhmrghilhdrtghomhdprhgtphhtthhopehpgh hsqhhlqdhhrggtkhgvrhhssehpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ic6394509:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id E171718E006C; Wed, 12 Nov 2025 15:38:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: AE1r89ybsZ1g Date: Wed, 12 Nov 2025 21:37:51 +0100 From: "Joel Jacobson" To: "Arseniy Mukhin" Cc: pgsql-hackers Message-Id: <074cfe3f-b59f-4c42-8dab-f845f691ae0e@app.fastmail.com> In-Reply-To: References: <6899c044-4a82-49be-8117-e6f669765f7e@app.fastmail.com> <165530.1752362320@sss.pgh.pa.us> <02a7cd37-e2fc-4212-8b19-f8c239c95fb8@app.fastmail.com> <96f00bf1-cc9d-4520-9d02-9e14e7767c88@app.fastmail.com> <30c2aa7d-dd6c-4b68-a2e4-f217a1a34acf@app.fastmail.com> <0b4d402a-9ac2-4aa8-acf8-8231dbe579ea@app.fastmail.com> <3095599.1758644879@sss.pgh.pa.us> <0dc6a2cc-5216-4dc1-9dd2-430cafc6095b@app.fastmail.com> <52CC167F-763B-4ECA-B0B4-DAB381816828@gmail.com> <9186C6D0-F7A9-482A-9183-89E530B57E36@gmail.com> <1073593.1759423179@sss.pgh.pa.us> <4bd5e6c4-6fa7-44bb-869d-59a32a331fa8@app.fastmail.com> <85828f29-e72e-4400-94f3-9a69bc8dc239@app.fastmail.com> <2495353.1759860890@sss.pgh.pa.us> <8aeae418-92a6-4bbd-9c06-9574c79e59f7@app.fastmail.com> <2531672.1759868124@sss.pgh.pa.us> <474efa78-337c-41cd-a73a-f845a0115109@app.fastmail.com> <2749343.1759949176@sss.pgh.pa.us> <8bfca2be-1ec0-4e15-aafb-0b7b661fe936@app.fastmail.com> <9eba307f-f2fb-48f0-9507-2e197f39ef9e@app.fastmail.com> <8c71183a-0d28-4bcf-a806-78446ff95404@app.fastmail.com> <1009807.1760476747@sss.pgh.pa.us> <1F7227F5-C33D-4E2C-8511-33F1468590D0@gmail.com> <0a5a20d3-4621-46b3-b2ab-903f63a20dea@app.fastmail.com> <6F913129-ABEF-4004-AAF3-F22FC34!29AE8@gmail.com> <1547585.1760645808@sss.pgh.pa.us> <14865EB6-0BF4-462B-9072-10BDAC10C052@gmail.com> <0BCA1C2D-B92C-459E-B1A6-6D06BA4C62CF@gmail.com> <55d24cbb-e9ef-491f-a99b-b3dbd7cecdf9@app.fastmail.com> <38574cad-e90d-47b7-a015-753bb6bbc360@app.fastmail.com> <66631FB7-5BEA-4ED5-A694-9AD8B9CCFEE8@gmail.com> <4b7b49a5-5e1a-44a8-93e0-60457d15cb1d@app.fastmail.com> <82DEA2B6-6FC5-4A79-BDE3-1FD72F104A6E@gmail.com> <38de1036-d8cf-420c-b845-edb5a946b191@app.fastmail.com> <87E40BF8-8877-4DBD-9040-99AF8A4E6358@gmail.com> <7556f0d4-03fd-451a-bd34-5f62b424319a@app.fastmail.com> <290910DE-9A03-4AE6-B348-073D5DA96ACC@gmail.com> <4B243750-12BE-4C16-A769-A803268F40E3@gmail.com> <4605CAD6-69D5-4082-B96C-91FC0DE5399D@gmail.com> <294e1641-d658-4d43-8671-60e8ff860532@app.fastmail.com> <26d4dd6a-cfc5-4efc-9704-9cd3216ed712@app.fastmail.com> <7456ec96-7a9c-45a0-988e-ba1c7f9ec937@app.fastmail.com> Subject: Re: Optimize LISTEN/NOTIFY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 12, 2025, at 17:57, Arseniy Mukhin wrote: > On Tue, Nov 11, 2025 at 7:35=E2=80=AFPM Joel Jacobson wrote: >> I'm therefore attaching v24 again, but renamed to v26. > > Thank you for the new version! Thanks for reviewing! > I read direct advancement part of v26, one point about it: > > The comment in SignalBackend says: > > * Listening backends that are not advancing and are station= ary at > * a position somewhere in the range we just wrote, can safe= ly be > * direct advanced to the new queue head, since we know that= they > * are not interested in our messages. > */ > > IIUC it's impossible for the listener to stop somewhere in between > queueHeadBeforeWrite and queueHeadAfterWrite. If the listener has > managed to read the first notification from the notifier, it means the > notifier transaction is complete and the listener should stop only > after reading all notifications (so we should always see pos =3D > queueHeadAfterWrite or further). Here is what I think can happen: If the notifications written by the notifier fills the current page, it updates QUEUE_HEAD, and if a listening backend then enters asyncQueueReadAllNotifications at this time, it will set its local `head` variable to the current QUEUE_HEAD, and when the notifier continues filling the next page, it will again update QUEUE_HEAD, and PreCommit_Notify will overwrite queueHeadAfterWrite with the QUEUE_HEAD. Sequence of events: 1. In the notifier, PreCommit_Notify calls asyncQueueAddEntries, which updates QUEUE_HEAD when the page is full, (and sets queueHeadAfterWrite to this value). 2. At this time, a listener wakes up and asyncQueueAddEntries reads the current QUEUE_HEAD value and stores it in its local `head` variable, and starts reading up to this pos. 3. In the notifier, PreCommit_Notify calls asyncQueueAddEntries the second time, which updates QUEUE_HEAD, and sets queueHeadAfterWrite to the final value before returning. For this reason, I think the listener could actually stop in between queueHeadBeforeWrite and queueHeadAfterWrite, since it's local `head` variable could get the intermediary QUEUE_HEAD value, when a page is full. /Joel