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 1w0SEV-001v5m-1t for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 22:40:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w0SET-00CL8W-38 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Mar 2026 22:40:50 +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 1w0SES-00CL8L-2b for pgsql-hackers@lists.postgresql.org; Wed, 11 Mar 2026 22:40:50 +0000 Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w0SEP-00000002Cyf-3VHL for pgsql-hackers@postgresql.org; Wed, 11 Mar 2026 22:40:49 +0000 Received: from phl-compute-10.internal (phl-compute-10.internal [10.202.2.50]) by mailfout.stl.internal (Postfix) with ESMTP id EB66E1D00059; Wed, 11 Mar 2026 18:40:43 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Wed, 11 Mar 2026 18:40:44 -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=fm1; t=1773268842; x=1773355242; bh=OfgJI0qZJl Ev/jqhmpvofO849GAJ2SpG62G8kv/vWmU=; b=kQIX5X1isV7LvQ2dETU6aJQdWQ tBu3hhRK51KpSg2U/OzIHK6LpJZfpjslVBsgD6/vTGxnBYjg8JlJL80k6Mk9qgdJ 4frjcxDRQ03M2JHXgGSXBxDc+wk5x905NKW1Tl1a2SuyS9TbVLjxHT/tQEH2MCP4 XnxLMADMlV36i9CFi8jBt1VC/87wzSyfS9IiIHsPmCpID93I573AL6JUNDbFSvRG YqE+wZtnjnjyKcmdaYbm8FkxHGOI552iDtOjb4DlAGvgg3B/tvgY1Xr1yQwp5PpZ 5+WanRHSZzOLd9zY5YunVJqTV1FhDcZpdkOxw4GlBDJ71jwADTV5E6WBfqgQ== 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=fm1; t= 1773268842; x=1773355242; bh=OfgJI0qZJlEv/jqhmpvofO849GAJ2SpG62G 8kv/vWmU=; b=4N7yGfF4Ud0Npo2niTaJDuKYTnMUk2cZPLYBF3QYMmpHOtcVTuS D9KsXwPgb7KINb4LAEenOUf/OXxid7M+0yOQkZzAgGVSWeerxXQ5UyAUlaweSUBF KKs0MjUFxDBlcic+aB66lXectNJOZ0pGaU31PZyYxdaH9s2Ntq/ky+JGqUMsFy+Z FoEi6Om2e5lOwO0C85YgLEOKvlZ1vu1BdIqTh0WgIjWb6Q3wtjqUGgE0g3WM9mHQ DG5K9l6RPOcEItbWKlItcXLi8uVyOumwn3akfjGsvMTYco6Bzw//X/HhWkf8EUiv sdkeGOSn7wumB5V4f2yM3QcfJYFtYOOZUWA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvkeehuddvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesmhdtsfertddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepleeileeiveehvefhhedvgfevteetvdeuvefguddufefffeelfeffueetiefh fedunecuffhomhgrihhnpegrnhgrrhgriigvlhdruggvnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprghnughrvghssegrnhgrrhgriigvlhdr uggvpdhnsggprhgtphhtthhopeelpdhmohguvgepshhmthhpohhuthdprhgtphhtthhope gsohgvkhgvfihurhhmodhpohhsthhgrhgvshesghhmrghilhdrtghomhdprhgtphhtthho pehmvghlrghnihgvphhlrghgvghmrghnsehgmhgrihhlrdgtohhmpdhrtghpthhtohepmh hitghhrggvlhdrphgrqhhuihgvrhesghhmrghilhdrtghomhdprhgtphhtthhopehrvghs hhhkvghkihhrihhllhesghhmrghilhdrtghomhdprhgtphhtthhopehrohgsvghrthhmhh grrghssehgmhgrihhlrdgtohhmpdhrtghpthhtohepthhhohhmrghsrdhmuhhnrhhosehg mhgrihhlrdgtohhmpdhrtghpthhtohephhhlihhnnhgrkhgrsehikhhirdhfihdprhgtph htthhopehnohgrhheslhgvrggusghorghtrdgtohhmpdhrtghpthhtohepphhgshhqlhdq hhgrtghkvghrshesphhoshhtghhrvghsqhhlrdhorhhg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 Mar 2026 18:40:42 -0400 (EDT) Date: Wed, 11 Mar 2026 18:40:41 -0400 From: Andres Freund To: Noah Misch Cc: Heikki Linnakangas , Melanie Plageman , Kirill Reshke , Matthias van de Meent , pgsql-hackers@postgresql.org, Thomas Munro , Robert Haas , Michael Paquier Subject: Re: Buffer locking is special (hints, checksums, AIO writes) Message-ID: References: <5dwlfu2jyzkyf3nrlzxxblxctb6xio5es73ptgsahjnmfu5miu@772rc764hfhi> <4csodkvvfbfloxxjlkgsnl2lgfv2mtzdl7phqzd4jxjadxm4o5@usw7feyb5bzf> <5ubipyssiju5twkb7zgqwdr7q2vhpkpmuelxfpanetlk6ofnop@hvxb4g2amb2d> <68e89de8-5f6c-4eaf-a800-e16a5e487667@iki.fi> <20260215195239.ce.noahmisch@microsoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="yfnpukktxfv6vdpt" Content-Disposition: inline In-Reply-To: <20260215195239.ce.noahmisch@microsoft.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --yfnpukktxfv6vdpt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On 2026-02-15 11:52:39 -0800, Noah Misch wrote: > On Sat, Feb 07, 2026 at 12:44:25PM +0200, Heikki Linnakangas wrote: > > On 03/02/2026 00:33, Andres Freund wrote: > > > - The way MarkBufferDirtyHint() operates was copied into > > > heap_inplace_update_and_unlock(). Now that MarkBufferDirtyHint() won't work > > > that way anymore, it seems better to go with the alternative approach the > > > comments already outlined, namely to only delay updating of the buffer > > > contents. > > > > > > I've done this in a prequisite commit, as it doesn't actually depend on any > > > of the other changes. Noah, any chance you could take a look at this? > > v12-0001-heapam-Don-t-mimic-MarkBufferDirtyHint-in-inplac.patch looks good. > > How about this: > > > > * We avoid that by using a temporary copy of the buffer to hide our > > * change from other backends until it's been WAL-logged. We apply our > > * change to the temporary copy and WAL-log it before modifying the real > > * page. That way any action a reader of the in-place-updated value takes > > * will be WAL logged after this change. > > Either v12 or v12 w/ this edit is fine with me. I find this proposed text > redundant with nearby comment "register block matching what buffer will look > like after changes", so I mildly prefer v12. Thanks for the review! I pushed this and many of the later patches in the series. Here are updated versions of the remaining changes. The last two previously were one commit with "WIP" in the title. The first one has, I think, not had a lot of review - but it's also not a complicated change. I see decent performance improvements with a fully s_b resident pipelined pgbench -S with 0002+0003, ~7-8% on an older small two socket machine. The improvement is just from reducing the number of atomic operations on contended cachelines (i.e. inner btree pages). Without pipelining the difference is smaller (1-2%), because of the context switches are the bigger bottleneck. More extreme worloads involving an index nested loop join benefit more. E.g. the setup and query from https://anarazel.de/talks/2024-05-29-pgconf-dev-c2c/postgres-perf-c2c.pdf slide 23, show a 25% improvement on the same 2 socket machine. We could probably do something similar for the also very common combination of PinBuffer() + LockBuffer(), but I think it'd be a fair bit more complicated, and would require new APIs, rather than just using existing APIs more widely. Greetings, Andres Freund --yfnpukktxfv6vdpt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v13-0001-bufmgr-Don-t-copy-pages-while-writing-out.patch"