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 1w9vi0-001tmy-24 for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 01:58:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9vhz-00DPRn-06 for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 01:58:27 +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 1w9vhy-00DPRe-01 for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 01:58:27 +0000 Received: from fhigh-a5-smtp.messagingengine.com ([103.168.172.156]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w9vhv-000000010ZQ-0n3r for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 01:58:26 +0000 Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.phl.internal (Postfix) with ESMTP id D4F9114001F2; Mon, 6 Apr 2026 21:58:20 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Mon, 06 Apr 2026 21:58:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc: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=1775527100; x=1775613500; bh=2xi6Prldo9 dio084mwEgwtsLj5FG4tV4qmoa2bqbGgc=; b=Hz/l3kIfTwhv+/GDKfq12om+gv rSODv0pbeXcwTlguJypyMlzxKIe4agk42cYS2OyKnsATNyTEv716Y2OrjpX6hGLp tltlGtFSLaDvk9s3Jtm28yUMvvJCBb3Fus8YEQl0b33C357Jo1wZ9eZQmj/okqAw 0/VskOxr6CZfBaH1Nj3RXZ6Z8HbkB7yvJWEHNmRrGN3CvcDowElOPAGC8q65HFUy Wgyp7xbB50zdGzKSnOvuQxbVowe3yNbnABG4HvstoEJNp8QsEKjWx6/PityU/bi6 DbYVn4EujgMZWTAa5L8XNoQh4tulxgirWDJFDgOTXsDbek082XzhbwYFxpSw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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= 1775527100; x=1775613500; bh=2xi6Prldo9dio084mwEgwtsLj5FG4tV4qmo a2bqbGgc=; b=wA/7sHvyNw7XBWrkLWbH5y0F67rwk5kqNDEd6MijoMLT3afpMBr dMJWCQ6FokLp3tfutI+KjJ8ji3TLHF2xTPbGy0aq/617nhkm4CX/EljgiKzlcLkh wzJj9VL9GWc5gsa9FmxzrQ854kEUmU7aP3oUnD75BbqhxMPqcWdq1KznpO4JZYEZ xtmsoU/6r9kupmlP2mKhSZJp6mLzhKR49IS7YpwWHCT14uLPe2sZT7ivf3onEWCw YSvB7Lv962BNlooA/6gSx88ZnCGisSvhzuM5bPKea7BXELKCn9yVnNfSJrcT+mfD Dmle40kugAsek4UIbHPlhih8vRrJ0j4gcLA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduleefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfhfgggtuggjsehttdfstddttddvnecuhfhrohhmpeetnhgurhgvshcu hfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtffrrghtth gvrhhnpeeffffgledvffegtdevlefgtdeggffhvdekgfegteeiveejkeetudelveejhfeu geenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnh gurhgvshesrghnrghrrgiivghlrdguvgdpnhgspghrtghpthhtohepuddtpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprd horhhgpdhrtghpthhtoheprghhsegthigsvghrthgvtgdrrghtpdhrtghpthhtoheprghm ihhtrdhkrghpihhlrgduieesghhmrghilhdrtghomhdprhgtphhtthhopegsohgvkhgvfi hurhhmodhpohhsthhgrhgvshesghhmrghilhdrtghomhdprhgtphhtthhopehmihhhrghi lhhnihhkrghlrgihvghusehgmhgrihhlrdgtohhmpdhrtghpthhtohepshhrihhnrghthh dvudeffeesghhmrghilhdrtghomhdprhgtphhtthhopehvihhgnhgvshhhvddusehgmhgr ihhlrdgtohhmpdhrtghpthhtohepnhhorghhsehlvggruggsohgrthdrtghomhdprhgtph htthhopehpghhsqhhlqdhhrggtkhgvrhhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdr ohhrgh X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Apr 2026 21:58:20 -0400 (EDT) Date: Mon, 6 Apr 2026 21:58:19 -0400 From: Andres Freund To: Noah Misch Cc: Alvaro Herrera , vignesh C , Antonin Houska , Srinath Reddy Sadipiralla , Amit Kapila , Mihail Nikalayeu , Matthias van de Meent , Pg Hackers , Robert Treat Subject: Re: Adding REPACK [concurrently] Message-ID: References: <202604060918.qw5ms7cbr2hz@alvherre.pgsql> <20260407011056.50.noahmisch@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260407011056.50.noahmisch@microsoft.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-04-06 18:10:56 -0700, Noah Misch wrote: > On Mon, Apr 06, 2026 at 05:11:30PM -0400, Andres Freund wrote: > > heap_insert() > > ->CacheInvalidateHeapTuple() > > ->CacheInvalidateHeapTupleCommon() > > ->AssertCouldGetRelation() > > not being cheap and running a *lot*. > > > > Admittedly it's way worse if you build with -O0, which I tend to do to make > > debugging easier. > > > > In that config, the assert single-handled increases the time for a repack by > > 35% or so. > > > > > > Noah, is there any reason we need to do the AssertCouldGetRelation() before > > the !IsCatalogRelation(relation)? Given that the goal is to make > > RelationGetRelid() safe, it doesn't seem there is? > > By running AssertCouldGetRelation() during every INSERT statement, this > detects cases that would be unsafe when the target of the INSERT happens to be > a system catalog. I see. > Little of our INSERT/UPDATE coverage targets a system catalog. Sure. We do have plenty DML doing heap_insert/update however. > Hence, the current position is better for detection. What if we returned early in AssertBufferLocksPermitCatalogRead() if InterruptHoldoffCount == 0? That'd only fail if some code manually did a RESUME_INTERRUPTS() to balance the one acquired as part of the content lock? > I wonder if this got slower in v19. In v14-v18, the assert's cost is > proportional to the number of held lwlocks, often 0 or 1. In v19, it's > proportional to PrivateRefCountHash cardinality. Yea, plausible. It will only scan PrivateRefCountHash if PrivateRefCountOverflowed overflowed, but it did overflow in the case I was testing... Greetings, Andres Freund