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 1uiueH-00HZHz-4U for pgsql-bugs@arkaria.postgresql.org; Mon, 04 Aug 2025 12:50:41 +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 1uiueF-001G86-Oh for pgsql-bugs@arkaria.postgresql.org; Mon, 04 Aug 2025 12:50:39 +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 1uiueF-001G7y-0d for pgsql-bugs@lists.postgresql.org; Mon, 04 Aug 2025 12:50:39 +0000 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1uiueC-000gYu-15 for pgsql-bugs@lists.postgresql.org; Mon, 04 Aug 2025 12:50:38 +0000 Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.stl.internal (Postfix) with ESMTP id 58BEB7A02A1; Mon, 4 Aug 2025 08:50:36 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Mon, 04 Aug 2025 08:50:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm1; t=1754311836; x= 1754398236; bh=eTSgtVfSTvVjEdDshm1z6wxjQ8u0yJ725vSHDms+lyc=; b=a QldvdPigYsWzN/aRU4KOrcXtqNC/Mv8jaCz19cJfIeA2UVPqN4EqTGOh/43FDRIo 17xfbkNPtK3EC6K8lRL8A3yf7yHSjIMSmboRyTPycqLUgfYfVN+V/7cmRnNX5xte mv6TBgSeZ53cWk3ddGA4syV2Tyw0i2rNXsimHQ1GEWZ44XBK15s8d3tOqzCHTQ/7 yIULadEYGEZfmo7qEaxmVwcIPpzPPCftps0642GDcAoBlmlgQ1xSAiISqJFZvnBJ 99TsWULEAGKzIXt229DvbxLN0aWqKI+H2NJi284Rxs9ICEt06+MfhS1/knI/6oyP d8uiifh+X+y5no1HID7/Q== 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 :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1754311836; x=1754398236; bh=e TSgtVfSTvVjEdDshm1z6wxjQ8u0yJ725vSHDms+lyc=; b=GkdqLiPR1i7ViQxED mMzmyIjCarwQ94Ucq5XHrE7U4m9bbhxqLfU2O5AoioIdbv2ZOVIo8sj1frk3eSx4 0PIKjFhLwBFsFFAMfkcWpHN6/4mVRNxiXQ0PAJ8tAeCrhIBmDERMrKDjSfzmTws6 J01BfjUSAl874fjExk2OPVxaGyf8dwYAcW5VzILiE6zxgsWLplxwooRNjWqZqRgf 9Z2SDTQZHUYrW8mpfZO029G/eEfa7Od4z3mlKd2MD06P+9nHQF11wzD39+j6cAI1 cyyfPSLxYWWV6K/pbGTov6NhTqDuuAaY25jLGvvHXbL6B6C2PLZnLMlOMknxfdGd BkCgQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduuddvfeegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheplmhlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvqeenucggtf frrghtthgvrhhnpeetuedvheffkeevgfeuheevteevkefggedttdeufeeuheduuddthfef fffhjeefffenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgv sehkuhhrihhlvghmuhdruggvpdhnsggprhgtphhtthhopeehpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopehkuhhrohgurgdrhhgrhigrthhosehfuhhjihhtshhurdgtohhm pdhrtghpthhtohepughilhhiphgsrghlrghuthesghhmrghilhdrtghomhdprhgtphhtth hopegvgigtlhhushhiohhnsehgmhgrihhlrdgtohhmpdhrtghpthhtohepvhhighhnvghs hhdvudesghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdgsuhhgsheslhhish htshdrphhoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 4 Aug 2025 08:50:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1754311834; bh=JnZD2zbwa4H4VD9UJdeLBPLRGY3YdxkMOm+2MLvxwNA=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=ZQvICVqbj+xkOPpd7Cg9rCP4j8Ptfw2lHLwq8qrlo1kQrPh2gQLi7oQSrGDGiHgiJ xUaBlt1FqweZ16ksGXNImRrhtpdP7fAhYaA8wA6vdw38dHegAvFwPu3FBgl/oRt5pb P7ilbUtXv/+so6FHEcVXPfSSwX6ZffepBq33ag4HszUYnjK4d8eAsRDpz5KgunOnol ErWpv0xLOC8gro/PAMdMX4iPphhUk/hUqt4bdW5HjUw94vYoHZCb8Ger3ar2mvfyOQ 6ifNFchHbeCpnLh5ohNFoj4dEKzt0fhW/KE9BqecuaL8LJ9mZAq/irKC2ZGfSD5iY7 2xhyYbf3OPVXg== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 2D79590; Mon, 4 Aug 2025 14:50:34 +0200 (CEST) Date: Mon, 4 Aug 2025 14:50:34 +0200 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Dilip Kumar Cc: vignesh C , "Hayato Kuroda (Fujitsu)" , "exclusion@gmail.com" , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database Message-ID: <202508041250.6qjjfgnqe7mi@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025-Aug-04, Dilip Kumar wrote: > I have worked on this and produced a first version of patch, let's see > what others think about this idea. It would have been better if we > could use SysCache for rechecking the subscription, but since we are > not connected to the database in the launcher we can not use the > SysCache, at least that's what I think. I think it's reasonable to recheck after locking. There's a comment in DropSubscription that says we get AEL, which is no longer true. In is_subscription_exists() you should use the index on OID instead of seqscanning the catalog without a scankey; also I think the name ought to be "does" rather than "is". I think it's really odd that that function opens and closes a transaction; sounds to me that something like that really belongs in the caller (frankly the same is true with the other function that your comment references). Why isn't systable_beginscan being used to scan the catalog? I think with this coding, the resource owner for this new lock is NULL. Is this really a good approach? Maybe there should be a resowner here. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "Always assume the user will do much worse than the stupidest thing you can imagine." (Julien PUYDT)