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.94.2) (envelope-from ) id 1vCuKI-001mZm-Cz for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Oct 2025 06:34:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vCuKF-004SPq-Ua for pgsql-hackers@arkaria.postgresql.org; Sun, 26 Oct 2025 06:33:58 +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.94.2) (envelope-from ) id 1vCuKF-004SP8-0b for pgsql-hackers@lists.postgresql.org; Sun, 26 Oct 2025 06:33:58 +0000 Received: from fout-b4-smtp.messagingengine.com ([202.12.124.147]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1vCuKC-003oNd-02 for pgsql-hackers@postgresql.org; Sun, 26 Oct 2025 06:33:57 +0000 Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id C5D3B1D000DA; Sun, 26 Oct 2025 02:33:54 -0400 (EDT) Received: from phl-imap-03 ([10.202.2.93]) by phl-compute-04.internal (MEProxy); Sun, 26 Oct 2025 02:33:54 -0400 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=fm2; t=1761460434; x=1761546834; bh=szwBi3abkvAWFLEZTMrm6dKQpAqkPJZOjL0zFebYFug=; b= K7qIuP/E6bvTfjam0j7NX/zX0eNMGBDDxBupimMu5cbXtQVwQKEzFj4OTbyRlCSF eY4os6qUQ5Jc2d7SLDhuYnKI2dZC97xEWIyzo21SwhaveyLEObckC2rz/5z1lHUE 3RfmCNgyTw0AmoI3V4IJgDYYBA+dWOtmCXa+uJc+Ugfi7XypbG+H53p8R70i1u1S BTLy+CuaeBcPCKnMRH3ALspaAr4IwfUsjU9Vs14G1gRAQFBiQLdG89VmV84D+P/0 6qCv2MyMz2SXP9hUERs+U4cpvcB7q/HCqrNUxICL7BsD3VuFaJF5RNjWbRYv0s4B s7wApUk173yVH5/gXS7QUg== 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=fm2; t=1761460434; x= 1761546834; bh=szwBi3abkvAWFLEZTMrm6dKQpAqkPJZOjL0zFebYFug=; b=a aq1zNQElGtFAvMpanJKwZkhqaWtC+UqEHIPzLT4pHi7eYsxngN/ii0fF9S4Pr1t8 69oIjF3G4gjR8DHG8/MumPnVk1iACpCR3u05I4nS8wIJzMHhq8EuElT88hGcye2h fGAneU7ocxbUmj8cVrwo7ferVCnxkBt4VCNjFthWJ4JV7IQ81peVaWedxS8xgpvi nLDU/cN10TVUpnPfNE1+glsMlLg1jXwgKwcSO0y9Cthp4Rxvk5oubmI6BAdVI7Rs glWcQHK7GCQeqQokKEVfSICjIkYHO9zJ/GZBh3h/tfvqIO0fGsxlw1ihbZMWFjEK ZUm5qCn37pMH3Vkqermnw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduheegfeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvvefkjghfufgtgfesthhqre dtredtjeenucfhrhhomhepfdflohgvlhculfgrtghosghsohhnfdcuoehjohgvlhestgho mhhpihhlvghrrdhorhhgqeenucggtffrrghtthgvrhhnpefggfeuheefheeufeegkeeife ffhffgvefftdduuefhfeelteegleehhfdtieevgfenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehjohgvlhestghomhhpihhlvghrrdhorhhgpd hnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrrhhs vghnihihrdhmuhhkhhhinhdruggvvhesghhmrghilhdrtghomhdprhgtphhtthhopehlih drvghvrghnrdgthhgrohesghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhh rggtkhgvrhhssehpohhsthhgrhgvshhqlhdrohhrghdprhgtphhtthhopehtghhlsehssh hsrdhpghhhrdhprgdruhhs X-ME-Proxy: Feedback-ID: ic6394509:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id BAEDD18E0069; Sun, 26 Oct 2025 02:33:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: AE1r89ybsZ1g Date: Sun, 26 Oct 2025 07:33:32 +0100 From: "Joel Jacobson" To: "Chao Li" , "Arseniy Mukhin" Cc: "Tom Lane" , pgsql-hackers Message-Id: <55d24cbb-e9ef-491f-a99b-b3dbd7cecdf9@app.fastmail.com> In-Reply-To: <0BCA1C2D-B92C-459E-B1A6-6D06BA4C62CF@gmail.com> 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> 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 Sun, Oct 26, 2025, at 05:11, Chao Li wrote: > I figured out a way to resolve the race condition for alt3: > > * add an awakening flag for every listener, this flag is only set by=20 > listeners > * add an advisory pos for every listener, similar to alt1 > * if a listener is awaken, notify only updates the listener=E2=80=99s = advisory=20 > pos; otherwise directly advance its position. > * If a running listener see current pos is behind advisory pos, then=20 > stop reading > > See more details in attach patch file, I added code comments for my=20 > changes. Now the TAP test won=E2=80=99t hit the race condition.=20 > ``` > # +++ tap check in src/test/authentication +++ > t/008_listen-pos-race.pl .. skipped: Injection points not supported by=20 > this build > Files=3D1, Tests=3D0, 0 wallclock secs ( 0.00 usr 0.00 sys + 0.03 c= usr =20 > 0.01 csys =3D 0.04 CPU) > Result: NOTESTS > ``` > > And with my solution, listeners longer will still use local pos, so=20 > that no longer need to acquire notification lock in every loop. This sounds promising, similar to what I had in mind. I was thinking about the idea of using the advisoryPos only when the listening backend is known to be running (which felt like it would need another shared boolean field), and to move its pos field directly only when it's not running, since if it's running we don't need to optimize for context switching, since it's by definition already running. What I wanted to investigate what all the concurrency situations that we can imagine, i.e. to permutate all possible differences we can think of into a truth table, and reason about each case. The ones I can think of are, from the perspective of SignalBackends, reasoning about a specific listening backend: {is interested in the notifications, is not interested in the notificati= ons} x {wakeupPending=3Dfalse, wakeupPending=3Dtrue} x {pos < queueHeadBeforeWrite, pos =3D=3D queueHeadBeforeWrite, pos > queu= eHeadBeforeWrite, pos =3D=3D queueHeadAfterWrite, pos > queueHeadAfterWr= ite} x {is running, is not running} This gives 2x2x5x2=3D40 states to reason about. Some of these combinatio= ns are probably impossible, I still think it would be good to include them and explain why they are impossible. > The patch stack is: v20 patch -> alt3 patch -> tap patch -> my patch.=20 > Please see if my solution works. > > I also made a tiny change in the TAP script to allow it to terminate g= racefully. I haven't looked at the code yet, tried to apply the patch but it fails: shasum of files: ``` ca54ffa02ac54efd65acce0d09b18e630b5d7982 0001-optimize_listen_notify-v2= 0.patch 5755701bb0e7ac7a0cea3abab9d74a0001b7b63a 0002-optimize_listen_notify-v2= 0.patch 5819e23b5760023be70d2582207b72164904e952 0002-optimize_listen_notify-v2= 0-alt3.txt 33d700dc0b3288d46705e85d381cb564d99079d1 0001-TAP-test-with-listener-po= s-race.patch.nocfbot 8ee716451bd5f85761b666712bdfd8b5d936f92d fix-race.patch ``` Trying to apply them on top of current master (39dcfda2d23ac39f14ecf4b83= e01eae85d07d9e5): ``` % git apply 0001-optimize_listen_notify-v20.patch % git apply 0002-optimize_listen_notify-v20.patch % git apply 0002-optimize_listen_notify-v20-alt3.txt % git apply 0001-TAP-test-with-listener-pos-race.patch.nocfbot % git apply fix-race.patch fix-race.patch:100: indent with spaces. (QUEUE_POS_PRECEDES(queueHeadBeforeWrite, pos) && QUEUE_POS_PR= ECEDES(pos, queueHeadAfterWrite))) && error: patch failed: src/backend/commands/async.c:250 error: src/backend/commands/async.c: patch does not apply error: patch failed: src/test/authentication/t/008_listen-pos-race.pl:8 error: src/test/authentication/t/008_listen-pos-race.pl: patch does not = apply ``` I'll try to resolve it manually, but in case you're quicker to reply, I'= m sending this now. /Joel