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.94.2) (envelope-from ) id 1ub1YA-00Cmv5-IT for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Jul 2025 18:35:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ub1XA-00HWPr-JT for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Jul 2025 18:34:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ub1XA-00HWPj-9j for pgsql-hackers@lists.postgresql.org; Sun, 13 Jul 2025 18:34:44 +0000 Received: from forwardcorp1d.mail.yandex.net ([178.154.239.200]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1ub1X7-0076le-2j for pgsql-hackers@lists.postgresql.org; Sun, 13 Jul 2025 18:34:44 +0000 Received: from mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net [IPv6:2a02:6b8:c43:4603:0:640:d209:0]) by forwardcorp1d.mail.yandex.net (Yandex) with ESMTPS id C303860A3D; Sun, 13 Jul 2025 21:34:37 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:44f::1:20]) by mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id aYOvQB4GnGk0-GLcQzEK4; Sun, 13 Jul 2025 21:34:37 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1752431677; bh=gl9SWCjaILgIqB9lQdHm4wh3Rt6G256aXPlOFxATPJM=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=1PFYQMkCxKkyHQvutEhN5kZhf8DF7+uVkIUFm6XRCwPN4Pp8whfsg3a5h45gGaXRY HFk9vIBLbODBG5ABnj74QG6oUFL2QokPAQn4ixBeLGRXnnidH1TcgOvId2mpIoGHNZ pQ87yshcfhwn1BM+oo9O1y0/fHXmtClmysbXil30= Authentication-Results: mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\)) Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) From: Andrey Borodin In-Reply-To: Date: Sun, 13 Jul 2025 23:34:26 +0500 Cc: PostgreSQL Hackers , Andres Freund , Robert Haas Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Melanie Plageman X-Mailer: Apple Mail (2.3826.600.51.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 12 Jul 2025, at 03:19, Melanie Plageman = wrote: >=20 > remove the xl_heap_visible struct Same goes for VISIBILITYMAP_XLOG_CATALOG_REL and XLOG_HEAP2_VISIBLE. But = please do not rush to remove it, perhaps I will have a more exhaustive = list later. Currently the patch set is expected to be unpolished. I just need to absorb all effects to have a high-level evaluation of the = patch set effect. I'm still trying to grasp connection of first patch with = Assert(prstate->cutoffs) to other patches; Also, I'd prefer "page is not marked all-visible but visibility map bit = is set in relation" to emit XX001 for monitoring reasons, but again, = this is small note, while I need a broader picture. So far I do not see any general problems in delegating redo work from = xl_heap_visible to other record. FWIW I observed several cases of VM = corruptions that might be connected to the fact that we log VM changes = independently of data changes that caused VM to change. But I have no = real evidence or understanding what happened. Best regards, Andrey Borodin.=