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 1l7T0Y-0008Ha-WA for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Feb 2021 01:00:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l7T0X-0001lg-Uu for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Feb 2021 01:00:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7T0W-0001lZ-FC for pgsql-hackers@lists.postgresql.org; Thu, 04 Feb 2021 01:00:29 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7T0R-0007C3-MJ for pgsql-hackers@postgresql.org; Thu, 04 Feb 2021 01:00:27 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4F3E35C0132; Wed, 3 Feb 2021 20:00:21 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 03 Feb 2021 20:00:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=RrwQBm3YZTsUlzPTicoXmW5QRQS 8W9VkaEN83OsOyuU=; b=Aqh8Arir/RZzw+J2fJpnuthJ17BqtPojXFqzAVZQV3p yCDRwzTkQfTutKllDLV7nd1LvAUpsxA9ocGDY0dh4Mz0GFCuZKl7/1fsWv0PIAhW g8l+KhHjVV7A/H/a3MtqRnZwkAB7R1M4Y/oqwOAJ55GXVpQMKLtwLqqZ3/q3lGwB QaTExe73iWWVh7/h8SfCeAg9mPKs80v/kGVGzx4hpoSIRqRig/OGLv+9bwKb+Oxd S0/srexHhykMcdWk5iTn85Sq5YXvxm3pk+Klf1jxsbJr70TZsdNXqtYKTVUDqWMt 71RmZHWpGdGJVxNWik8ilXQX8fYw4BHRPdhsqh6Hrhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RrwQBm 3YZTsUlzPTicoXmW5QRQS8W9VkaEN83OsOyuU=; b=LNXae6JHn4l7ptZtbg6Epv hwupUyH9/n1XvcIkmHx1u8SO+gBJhgIAFw13LgLE9k/cKVMuc0va7UsBniFCIByj Y6u0HE2P/QadtvAXs44GY2VV3628QGOGncjJ04v7lqD3ucZWf2VG+HX4cLj+0QpF BUhmIkqznaV32lIld4vXa6VvV3cD2Yp4o5hdOFDFWzgT5gy8qwnELvn53IGDKsRU EbJ1nXQoujmmjRwlWoZg8uHos3QhiMOUKQXahUGiZ0UhY7BoJVyD/HBsppr1mefL nIsw14f6fqPnBoOZZMKBxNA/Vl0KNVqkGl3RVjs0UriNX/jFGWvXwlKwwOIbdFgw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeefgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepudekhfekleeugeevteehleffffejgeelueduleeffeeutdelffeujeffhfeu ffdunecukfhppeeijedrudeitddrvddujedrvdehtdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgiivghlrdgu vg X-ME-Proxy: Received: from intern.anarazel.de (c-67-160-217-250.hsd1.ca.comcast.net [67.160.217.250]) by mail.messagingengine.com (Postfix) with ESMTPA id C47A21080066; Wed, 3 Feb 2021 20:00:20 -0500 (EST) Date: Wed, 3 Feb 2021 17:00:19 -0800 From: Andres Freund To: Bruce Momjian Cc: PostgreSQL-development Subject: Re: Multiple full page writes in a single checkpoint? Message-ID: <20210204010019.pyasieusrgi6cead@alap3.anarazel.de> References: <20210203230556.GB11069@momjian.us> <20210203232913.t3fng3evt4qucm3g@alap3.anarazel.de> <20210204002125.GC11069@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210204002125.GC11069@momjian.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 2021-02-03 19:21:25 -0500, Bruce Momjian wrote: > On Wed, Feb 3, 2021 at 03:29:13PM -0800, Andres Freund wrote: > > Changing this is *completely* infeasible. In a lot of workloads it'd > > cause a *massive* explosion of WAL volume. Like quadratically. You'll > > need to find another way to generate a nonce. > > Do we often do multiple writes to the file system of the same page > during a single checkpoint, particularly only-hint-bit-modified pages? > I didn't think so. It can easily happen. Consider ringbuffer using scans (like vacuum, seqscan) - they'll force the buffer out to disk soon after it's been dirtied. And often will read the same page again a short bit later. Or just any workload that's a bit bigger than shared buffers (but data is in the OS cache). Subsequent scans will often have new hint bits to set. > Is the logical approach here to modify XLogSaveBufferForHint() so if a > page write is not needed, to create a dummy WAL record that just > increments the WAL location and updates the page LSN? > (Is there a small WAL record I should reuse?) I think an explicit record type would be better. Or a hint record without an associated FPW. > I can try to add a hint-bit-page-write page counter, but that might > overflow, and then we will need a way to change the LSN anyway. That's just a question of width... Greetings, Andres Freund