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 1wRttI-002n5N-0f for pgsql-hackers@arkaria.postgresql.org; Tue, 26 May 2026 15:40:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wRttG-004rvd-0n for pgsql-hackers@arkaria.postgresql.org; Tue, 26 May 2026 15:40:23 +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 1wRttF-004rvU-37 for pgsql-hackers@lists.postgresql.org; Tue, 26 May 2026 15:40:22 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wRttB-00000001XRB-1MRN for pgsql-hackers@postgresql.org; Tue, 26 May 2026 15:40:22 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 64QFe9cp014718; Tue, 26 May 2026 11:40:09 -0400 From: Tom Lane To: "Joel Jacobson" cc: "Arseniy Mukhin" , pgsql-hackers Subject: Re: [PATCH] Fix LISTEN startup race with direct advancement In-reply-to: References: <9835b0a4-9121-47ac-9c44-427b8b1a7f1b@app.fastmail.com> Comments: In-reply-to "Joel Jacobson" message dated "Wed, 20 May 2026 21:49:51 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14716.1779810009.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 26 May 2026 11:40:09 -0400 Message-ID: <14717.1779810009@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Joel Jacobson" writes: > Ohh, right, thanks for spotting. New version attached, 0001 and 0002 ide= ntical, > and 0003 now only contain the fix. I agree with this fix, but it seems to me that it changes the meaning of the ListenerEntry.listening flag in a rather fundamental way. I'm tempted to rename that flag to "committed" or something like that. (Both "listening" and "committed" appear in dozens of places in this file that are not references to this flag, so TBH I'd rather use a flag name that is not either of those words. But I can't think of a better name.) Also, while the proposed test cases are good for showing that there's a bug here, I'm disinclined to commit them. I do not think there is value in them proportionate to the cost of two new isolation-test instances. regards, tom lane