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 1utYvv-009vpZ-Jq for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 21:52:56 +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 1utYvt-005mX4-Kw for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 21:52:54 +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 1utYvt-005mWw-94 for pgsql-hackers@lists.postgresql.org; Tue, 02 Sep 2025 21:52:53 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utYvr-000Dtl-2W for pgsql-hackers@lists.postgresql.org; Tue, 02 Sep 2025 21:52:52 +0000 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-6188b5b113eso7874431a12.0 for ; Tue, 02 Sep 2025 14:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756849969; x=1757454769; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FolJnp7s716aiZNmbJbkNbNy7N+DYip8OtDqmK0qz00=; b=AsPM7YI1dqRp6Jo/K86RpHxTV8/eSh56p8V/U139N3zX0mlwC6GNPp+V7+rYpAhRxD ZK9c9San7XXdHHJF6/yLtlqdGLsF63ysU7nVntfCyzqbjyNLMDqCmXCiVCdEMKLjC6Yw WO01zSFqaUnzZgiEwkRftqVDPu7F9tUy0H7x7wWQUYR8eRoWN2TpCwiHHOip2HE49Fg7 DES6woRmOVwY4hDfdS+Eq2gVLrt7HEFM91xdpn0Dl5GLZ8AgdQx1V9+Sg3m8Gii2W1TK Xrw6OKvq5NvNk5xsKarJ2t6b7TGhduYs9IOZ4UrfA+NVjutlmZbOs6g7Oxa/YOyaDKg1 BZxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756849969; x=1757454769; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FolJnp7s716aiZNmbJbkNbNy7N+DYip8OtDqmK0qz00=; b=HwUB+hqky8ybhkuMsBjqJL/1tV0Uh/Tg5yXx3Aw7fr7zBkiEACX38/fjzPl4+kNQQ9 b4IhRiwgZgREY0fBPiDSdzucKyGS0V9MtXckZYZZPdLOSjGLeJkdnsWgttxOll8NXIXI hJu8g+nZLAB3jKf8zGeHW3cdaaK+KGAi6euM2iF8r5qPk39XCmFixwDrFEqYd6X7pOGZ lbE6cv6XuVrVqo4rEgnaKaGRMzgSyeDSuyUTq6ZRf7+RM3Q+3QqeT5k4axl/wuHenHq1 vD+ZjJCUHTiLKkXl/essdXsGzDgTLTRvFkCDEtrT1csahqd7v5plPpoS/w958yJXj/+g vbzA== X-Forwarded-Encrypted: i=1; AJvYcCXceZmo+f1mdm4TS+vMu2EDWLBV7gxVt2h6c3J/ETWPfzFVCcnHvo1nnsMm5lD6MxAXRLCjBZAoftY7BhWi@lists.postgresql.org X-Gm-Message-State: AOJu0YwkntkIHdoxzRn5FLphDQHlGnWUs/CKPYZTrisTKzwnv27ZgviP hnfx32yc0EiNsHaR6YGnZwsS8p5k75J/u3HieWyxpUNnx6sNgvbbwOJ9WasnL0GReREn6nKn027 GD0amAmg5avoHXFmp89AUifhD6HYy+uU= X-Gm-Gg: ASbGncvk2Lgp/MGWeahs/zBw7JdgovGGYgNRZeSJJGsilz6NwcB7p0KyKi1NnB1xLrw bYrAIzz2g/PVEFPQRi/dJXRbqG1nKSlitp9rt5OE/Fo3hdMkSNi8aFF5TEKFAUNSL4ln9dV5BX6 +7yRc9j+HE91pjMG1acEh2QVVbC+JwPkzWFUG2MG0siBp7sQc95Pax6j1t7ZvTqbUPGD2nAbWuK l/ohM90nNjIH8PLxw== X-Google-Smtp-Source: AGHT+IHSnZQHF5xYN4YYqjWLZjvld8nQeMUCirXikr0Lx+OAEqx+RSv/zraRuuUSKPfTOxy+kNsVojQsIyT0vJmLyi4= X-Received: by 2002:a05:6402:505c:b0:618:2fde:8fba with SMTP id 4fb4d7f45d1cf-61d26ac578fmr11213903a12.4.1756849968561; Tue, 02 Sep 2025 14:52:48 -0700 (PDT) MIME-Version: 1.0 References: <87DD95AA-274F-4F4F-BAD9-7738E5B1F905@yandex-team.ru> In-Reply-To: From: Melanie Plageman Date: Tue, 2 Sep 2025 17:52:37 -0400 X-Gm-Features: Ac12FXxpNLyjyo5u0QK36pAlm-sHtFiiLdv-Zx4crUJO09wWblXLJmQOXM7ZC-I Message-ID: Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) To: Kirill Reshke Cc: Andrey Borodin , PostgreSQL Hackers , Andres Freund , Robert Haas , Heikki Linnakangas Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Aug 28, 2025 at 5:12=E2=80=AFAM Kirill Reshke wrote: > > I did micro git-blame research here. I spotted only one related change > [0]. Looks like before this change pin was indeed needed. > But not after this change, so this visibilitymap_pin is just an oversight= ? > Related thread is [1]. I quickly checked the discussion in this > thread, and it looks like no one was bothered about these lines or VM > logging changes (in this exact pin buffer aspect). The discussion was > of other aspects of this commit. Wow, thanks so much for doing that research. Looking at it myself, it does indeed seem like just an oversight. It isn't harmful since it won't take another pin, but it is confusing, so I think we should at least remove it in master. I'm not as sure about back branches. I would like someone to confirm that there is no way we could end up with a different block of the VM containing the vm bits for a heap block during recovery than during normal operation. - Melanie