Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pg8S7-0007vL-Je for pgsql-hackers@arkaria.postgresql.org; Sat, 25 Mar 2023 18:17:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pg8S6-0001sP-Ea for pgsql-hackers@arkaria.postgresql.org; Sat, 25 Mar 2023 18:17:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pg8S6-0001sF-5H for pgsql-hackers@lists.postgresql.org; Sat, 25 Mar 2023 18:17:18 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pg8S2-0004JX-FX for pgsql-hackers@postgresql.org; Sat, 25 Mar 2023 18:17:17 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 04E1932009AE; Sat, 25 Mar 2023 14:17:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 25 Mar 2023 14:17:10 -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:sender :subject:subject:to:to; s=fm2; t=1679768229; x=1679854629; bh=nJ vnZyoyAcsKqJj7KQBjaA2YkEgN7IUXXiutWx+NPRY=; b=HttKUJppa6qlA4gtIz G9XymATApzXRj5ferxbuQ0ik6lQ/DIUCEHx+AKOsfVtz7gYgjH4Q8EHYISvmPVjw LidGk3PRVcl0ubQi6Q6OBQ4oIo55AoOETOnrzxxv1bIbKdmYfgxVfl6vhDFbJHmz Fum+1pHlII5KeD1wMxPdHz70q9mngMXNsvFs4hkUTyWo4to38L7dLya5SsSNeacD B7+aeI3/q1cmzf+Ce1yZhhxYFpeKIHp48VOFqCFn506LkWudY3cke6/iSylEoh48 yJ/BztYaxcc8V7lg9y003hC/0IIA2u1wT/zzBvsXHR8g6twCOM7uRvM3oDbHcyRa lj0w== 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:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1679768229; x=1679854629; bh=nJvnZyoyAcsKq Jj7KQBjaA2YkEgN7IUXXiutWx+NPRY=; b=iOBa64yA8XvXE5BokR+BoPu37QE8w lfFSm2ls6t0pUzqRz/5tvB8oS2klhjvoSRkhcMeHeu2Pbeg4FQAIIkfsAV4oXPEl iC10LdVefV3AT9F38iDf25wuA559RmddyxKqnE+nCCsonRM0LFm4UgY9bOPXCYvz gkoV12/iEa+GZJzy+H6xaZKBPtIEMTiPR3sXtWolM9JN81EOwDyQfRXUov+4nZRX Al2WWDL/QL1tNpikJM3RYWOMbLbSNAVuGSwGTIKj2eFhyeV0Ij2rQlYVvJ0AhcNf 3KToOmvbbVPUl6w8kGk2/K1TEdpJJnJ4DhTC7DbE+/RikV4fXltkn3sEQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdegkedguddufecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgu rhgvshcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtf frrghtthgvrhhnpedvffefvefhteevffegieetfefhtddvffejvefhueetgeeludehteev udeitedtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 25 Mar 2023 14:17:09 -0400 (EDT) Date: Sat, 25 Mar 2023 11:17:07 -0700 From: Andres Freund To: Tom Lane Cc: Tomas Vondra , pgsql-hackers@postgresql.org, Tomas Vondra , Anastasia Lubennikova , Pavan Deolasee , Jeff Janes Subject: Re: hio.c does visibilitymap_pin()/IO while holding buffer lock Message-ID: <20230325181707.at3kwsh7uvkhfype@awork3.anarazel.de> References: <20230325025740.wzvchp2kromw4zqz@awork3.anarazel.de> <0c11032a-d91b-8875-ab7b-4554776390c5@enterprisedb.com> <20230325163903.eu67kqcqo4llhc4u@awork3.anarazel.de> <2602455.1679763437@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2602455.1679763437@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2023-03-25 12:57:17 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2023-03-25 14:34:25 +0100, Tomas Vondra wrote: > >> Can't we ensure we actually lock the vm buffer too in ReadBufferBI, > >> before calling ReadBufferExtended? Or am I confused and that's not > >> possible for some reason? > > > Note that this is using P_NEW. I.e. we don't know the buffer location yet. > > Maybe the relation-extension logic needs to include the ability to get > the relevant vm page? I don't see how that's easily possible with the current lock ordering rules. At least without giving up using RBM_ZERO_AND_LOCK for extending or stuffing even more things to happen with the the extension lock held, which I don't think we want to. I don't think INSERT_FROZEN is worth that price. Perhaps we should just try to heuristically pin the right VM buffer before trying to extend? Thinking more about this, I think there's no inherent deadlock danger with reading the VM while holding a buffer lock, "just" an efficiency issue. If we avoid needing to do IO nearly all the time, by trying to pin the right page before extending, it's probably good enough. Greetings, Andres Freund