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 1vLuiJ-00E4KL-2r for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Nov 2025 02:48:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vLuiI-00H1xZ-0U for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Nov 2025 02:48:02 +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 1vLuiG-00H1xR-2w for pgsql-hackers@lists.postgresql.org; Thu, 20 Nov 2025 02:48:02 +0000 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vLuiA-000T9w-2V for pgsql-hackers@postgresql.org; Thu, 20 Nov 2025 02:48:00 +0000 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 49E7C7A0042; Wed, 19 Nov 2025 21:47:51 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Wed, 19 Nov 2025 21:47:51 -0500 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=fm3; t=1763606871; x=1763693271; bh=VaKAK8O3OB pguEBa0N7iWQaO4FIXZs0jPiAYuRWYonk=; b=MfFGTBF/STyV4545AbelqaeNE4 HSKYBdDmCG0nF3GumcR+ZknZzdiAhVmwMeeoNmwEDSEG4NOdzpvgsPj6T4d2vHbB 2mXBuHeqbtq58V/LN1jdv6eV3+8W95IweCnNmAUymAlViRr5tOzOOdwwX1ukiP+k neskVQ+M6JPnxzJx57M7YjxWuH1wAiG93cojntdI3MESWv/C3izUl36vM2ZuzHBs VYwgSVgdIwgNY/CitHg/TADfz9BA1m2wlkqQ7cBmRrfolYBQOp5ekMTD/0XPPPLy BEYRU3C30X1JtRKXbF3RsxYWjsJvSDt56anpTbpOoxas6ja05UpIce8RT1Hw== 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=fm3; t= 1763606871; x=1763693271; bh=VaKAK8O3OBpguEBa0N7iWQaO4FIXZs0jPiA YuRWYonk=; b=qMqMh1W00aXHcKkPA7JY9MTxx8PW0CvZvcmZt3/WtjsoUNkkTvZ QHGmBDIG7Z9teeQYsEhcO3hAtqrmiElT2IiPGjBejKKP+O5z1mL6gyy3PZTRJUQm 2HQuLy1+S44CNqYsoAkLW1naGXWAWL2F7d4ENGCProevFkuD6U807+B32yAe+Ted h1qv8/kgskuHByq795dLO+fYLXc7jcZOA838oAwQZjgUN1liS9PkTi4B3vkCBgAU GJ2SxsqBKBF74OxA2KPoqzpKvYZ8duHNgXJPX9jxj2IO7UwEK1yCNKyDm1SXhY0y oI5+jh/XFdrM3w3roJOmDNe+DVldk39V4Zw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvvdehledvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesmhdtsfertddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepfeefudejgffghfegheduffduieejgedtkeejhfevieevgeekgeekleeljeef keeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hnughrvghssegrnhgrrhgriigvlhdruggvpdhnsggprhgtphhtthhopeekpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopegsohgvkhgvfihurhhmodhpohhsthhgrhgvshesgh hmrghilhdrtghomhdprhgtphhtthhopehmvghlrghnihgvphhlrghgvghmrghnsehgmhgr ihhlrdgtohhmpdhrtghpthhtohepmhhitghhrggvlhdrphgrqhhuihgvrhesghhmrghilh drtghomhdprhgtphhtthhopehrohgsvghrthhmhhgrrghssehgmhgrihhlrdgtohhmpdhr tghpthhtohepthhhohhmrghsrdhmuhhnrhhosehgmhgrihhlrdgtohhmpdhrtghpthhtoh ephhhlihhnnhgrkhgrsehikhhirdhfihdprhgtphhtthhopehnohgrhheslhgvrggusgho rghtrdgtohhmpdhrtghpthhtohepphhgshhqlhdqhhgrtghkvghrshesphhoshhtghhrvg hsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 19 Nov 2025 21:47:50 -0500 (EST) Date: Wed, 19 Nov 2025 21:47:49 -0500 From: Andres Freund To: Matthias van de Meent Cc: pgsql-hackers@postgresql.org, Melanie Plageman , Thomas Munro , Heikki Linnakangas , Noah Misch , Robert Haas , Michael Paquier Subject: Re: Buffer locking is special (hints, checksums, AIO writes) Message-ID: <6rgb2nvhyvnszz4ul3wfzlf5rheb2kkwrglthnna7qhe24onwr@vw27225tkyar> References: <6kmid26do57ykqfpvq6iieniy4djsymhrypkjccazq5g4bbe6a@2y6owwv7qpex> <3je3ahgf7rrmmurxo6hnlhg5d3ffwfrtjwjxd6jm5srlv5iebp@vxqk5qtgmowr> <3w7v3w6a57jnssokap4k7thoekig72flnyhd4wp3yftzdd7lm7@f6lpcfen6hr7> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mhhc7c45w3dmihtp" Content-Disposition: inline In-Reply-To: <3w7v3w6a57jnssokap4k7thoekig72flnyhd4wp3yftzdd7lm7@f6lpcfen6hr7> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --mhhc7c45w3dmihtp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On 2025-10-09 17:16:49 -0400, Andres Freund wrote: > On 2025-10-09 16:35:44 -0400, Andres Freund wrote: > > I pushed a few commits from this patchset after Matthias' review > > (thanks!). Unfortunately in 5e899859287 I missed that the valgrind annotations > > would not be done anymore for the buffers returned by > > StrategyGetBuffer(). Which turned skink red. > > > > The attached 0001 patch centralizes the valgrind initialization in > > TrackNewBufferPin(), which 5e899859287 had added. The nice side effect of that > > is that there are fewer VALGRIND_MAKE_MEM_DEFINED() calls than before. The > > naming isn't the perfect match, but it seems fine to me. > > Forgot to say: I'll push this patch soon, to get skink back to green. Unless > somebody says something. We can adjust this later, if the comment and/or > placement of VALGRIND_MAKE_MEM_DEFINED() isn't to everyones liking. I have pushed that fix as well as the subsequent buffer header locking changes a while ago. Attached is a patchset that actually implements the buffer content locks in bufmgr.c. This isn't that close to a committable shape yet, but it seemed useful to get it out there. The first few patches seem closer, so it'll also be useful to narrow this down. 0001: A straight-up bugfix in lwlock.c - albeit for a bug that seems currently effectively harmless. 0002: Not really required, but seems like an improvement to me 0003: A prerequisite to 0004, pretty boring itself 0004: Use 64bit atomics for BufferDesc.state - at this point nothing uses the additional bits yet, though. Some annoying reformatting required to avoid long lines. 0005: There already was a wait event class for BUFFERPIN. It seems better to make that more general than to implement them separately. 0006+0007: This is preparatory work for 0008, but also worthwhile on its own. The private refcount stuff does show up in profiles. The reason it's related is that without these changes the added information in 0008 makes that worse. 0008: The main change. Implements buffer content locking independently from lwlock.c. There's obviously a lot of similarity between lwlock.c code and this, but I've not found a good way to reduce the duplication without giving up too much. This patch does immediately introduce share-exclusive as a new lock level, mostly because it was too painful to do separately. 0009+0010+0011: Preparatory work for 0012. 0012: One of the main goals of this patchset - use the new share-exclusive lock level to only allow hint bits to be set while no IO is going on. 0013: Prototype of making UnlockReleaseBuffer() faster and of using it more widely in nbtree.c 0014: Now that hint bits can't be done while IO is going on, we don't need to copy pages anymore. This needs a fair bit more work, as denoted by the FIXMEs in the code. I've tried to add detail to the more important commit messages, at least until 0012. I want to again emphasize that the important commits (i.e. 0008, 0012, 0014) aren't close to being mergeable. But I think they're in a stage that they could benefit from "lenient" high-level review. Greetings, Andres Freund --mhhc7c45w3dmihtp Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v6-0001-lwlock-Fix-currently-harmless-bug-in-LWLockWakeup.patch"