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 1ucOXS-00CRWe-Ht for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Jul 2025 13:20:42 +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 1ucOXQ-002gJj-Aj for pgsql-bugs@arkaria.postgresql.org; Thu, 17 Jul 2025 13:20:40 +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.94.2) (envelope-from ) id 1ucOXP-002gJU-I8 for pgsql-bugs@lists.postgresql.org; Thu, 17 Jul 2025 13:20:40 +0000 Received: from fhigh-a8-smtp.messagingengine.com ([103.168.172.159]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ucOXL-008G0M-07 for pgsql-bugs@lists.postgresql.org; Thu, 17 Jul 2025 13:20:37 +0000 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailfhigh.phl.internal (Postfix) with ESMTP id A13631400151; Thu, 17 Jul 2025 09:20:32 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-07.internal (MEProxy); Thu, 17 Jul 2025 09:20:32 -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=1752758432; x= 1752844832; bh=jA+sOwMMwM7KzHUTbvmd+EHsKoBxxU8wGNA3oeLJv8k=; b=f stTNXyiSd3Iaq3eXfJULqp+ksUS5oG0TuGtvxnrTvQ5n6iL51iqhgDtX6y4i3Luq 5C4X/mQ11zyZUdxqp8RwdxJau+yV+7D0ayl0vx+MMGzIgC7YD7OQOqoQxQuW7k9Y IXKQqRP1VdB4A3ppxS0PaebFxt0VGIonNbzyQRISD2Ygj7jvv2Y2dCOdkgKF0wDC hDOfY6Wxy3bMroKAfwxHi2zMWNN9vyEOcSCVUFf7OlN+C8txw1arpiTbrhHxQ3Dq vyamEkjNKsx6lUJ/tWhxGsLnHgLAXrOE9eLUNpXXiMHuIBeA9IdZ6+bXSmdCea0i j+62fOYQnF9H8Y3gL9Zsg== 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=fm2; t=1752758432; x=1752844832; bh=j A+sOwMMwM7KzHUTbvmd+EHsKoBxxU8wGNA3oeLJv8k=; b=lnXelm57IOfAYQqOD or+/l/LH6UQV36lx+2ybIcbMSHkv9HemzR4DWVbArnADolbUqb8fpD1yDi4/F/lm 1XX4eWbwtpvVe2sASDZ6hQGWNCZuj90eVFBQD41cbh+tKjJhANM/hM35wYmfNoSs PEjm90cfNQPlRRHetI3zqGeP2h7NOIbPrwgU6TOHBYGAzCf75D/jkOpcujNO9TBU VNVOCQzFgrlMHtm0TA8YVrVH5UFpH5bT94g6MkxHYJ6dsT5OEU5f93u+BtRwbvYK DC3yqILM+7AmKWwkSgb2WdWdNZxHLxKSfNLIXEodaaO82D58o142dweqEmjIc1f1 fmjJg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdeitdeilecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpemllhhvrghrohcu jfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgeskhhurhhilhgvmhhurdguvgeqnecuggftrf grthhtvghrnhepvddugfeukeeufeeivdfhlefhvdeguefhffetffetfefguddvieelledv fedtteehnecuffhomhgrihhnpehpohhsthhgrhgvshhqlhdrohhrghdpghhithhhuhgsrd gtohhmpdgvnhhtvghrphhrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgeskhhurhhilhgvmhhurd guvgdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohep rhhohhhithdvhedrnhgvghhisehgmhgrihhlrdgtohhmpdhrtghpthhtohepphhgshhqlh dqsghughhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 17 Jul 2025 09:20:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1752758430; bh=FD3Stkw/aXEZs5iXV6y/9O51VE/octeukI0hfD3ciRI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=O9RqmlTaQMQbmnbAC9CAsg65CCtDhCknkbFNz81YHnW1U9geEBVRWgIrVuOdfpGlQ 2RKfJifUHwqJM2M5D7ZtOqmm1gssE5DuEDZD8Iu7hitiRtYFsQBBVoO/OUUIm+27Yz nB/FKhKiCjMyqUyBB8XlL+jYUQPz+FmZIu+iQ3Megik+KTRRsoIOyj1c+jX5hky2cJ DbYCMtuUmriktJ/wSzisw/uC23lX7QS6jHaCYOgIKTm1a9I97k0P1kQkMnA7uuDqy+ WGHl4DgOp2ju9lks62Wuikl/x+bAhzOv8cMCtKRhUu/y9oUHKRMcR99g4AM+R65rKt uiA2CRL3NO4WA== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 3C0E790; Thu, 17 Jul 2025 15:20:30 +0200 (CEST) Date: Thu, 17 Jul 2025 15:20:30 +0200 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Rohit Negi Cc: pgsql-bugs@lists.postgresql.org Subject: Re: Correct Behaviour for Concurrent partition detach Message-ID: <202507171320.qcknqc6zoci2@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-Jul-17, Rohit Negi wrote: > *Question*: > Is this expected that any query(including select queries) running on > the parent table will block the DETACH partition query ? Is this also > expected if the running select query was not looking into the > partition being detached? Yeah, the DETACH needs to wait until those snapshots are gone, as you saw in the code. > *Inconsistency or clarification needed:* > Postgres doc says it will wait for all transactions on the parent table: > here > > But the Code says it will wait for all transaction that could've seen that > partition will be waited for: here > I read these both as saying the same thing. The "partitioned table" is the same as the "parent table". > In this line > , > Should it be passing the `*partrelid*` instead of `*parentrelid*` to only > wait for transactions involving the partition table? No, because what we want is to be able to rebuild a partition descriptor for the parent table which no longer contains the partition that's being detached. > Currently, I am suspecting that it's waiting for any query running on the > parent table regarding which partition that query points to. That sounds reasonable, yeah. I think the solution for your problem is along the lines of closing the cursor within a reasonable timeframe. Holding a query open for 40 minutes doesn't sound reasonable. If you need that, then you need to be able to cope with detach lasting that long. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Java is clearly an example of money oriented programming" (A. Stepanov)