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 1wutp2-000ydq-1A for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Aug 2026 15:27: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 1wutoz-001Kgh-2t for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Aug 2026 15:27:51 +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 1wutoz-001KgZ-1x for pgsql-hackers@lists.postgresql.org; Fri, 14 Aug 2026 15:27:50 +0000 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wutox-00000000j53-2e7O for pgsql-hackers@lists.postgresql.org; Fri, 14 Aug 2026 15:27:49 +0000 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4954a9e8490so13993555e9.1 for ; Fri, 14 Aug 2026 08:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786721267; x=1787326067; darn=lists.postgresql.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=fdtGeq6LjVb2oo26LkolctyXQJkDw/sFIh0gCJ4ROjY=; b=FuQBeVDceCWGfKOF2wZlfMnOf0ZrWYh8xggZfQrrpya19IFYs0FVAk5EME7+dTc9JV YXWjo45L8uv27rybO2qjzHAr1+DEH7H3wUodVo7igep54gzVw+HJe3h2Tmft0IRJRBt/ lFINrtEb9rFJnSS/RKaDi67HIXXU4nuezHtvlNXZmBWad5WrwA3Yn4p1d/A34c13SZHc 58mM3ydpG5uxgeCc22vQJDPl4T9V379WxsL5r2l+OsPrC3AAIklPvn0NVJn1L+nEdZFh PsBre4cebAlOUQb4aHXj2GsnZWAbGsITh9xzIISzmcFEG0B4cZtcjUaYK/aCtaJhXaFB fAjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786721267; x=1787326067; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=fdtGeq6LjVb2oo26LkolctyXQJkDw/sFIh0gCJ4ROjY=; b=PYZPDJihnQjoN6GV5lMzIQn1wwBRjTedvm7qIEtEmTmpxiXCsABg5iysh/le4K8WkI fAvWKwZiw3ukoe34fNc5IYpCFDYBvYyhqqzKMZXbuMoMMOs+RCDrywnSvILtjjOrnNaL bxzN6+GA6meQauyeGp4ObErkD7ZF4wNf1lNmQxcSWghhg4FDJdqNSL2zxBMQdpTexZ9t zbCz5Gn1K5tYfF1RtaRTgqOPqrgLBXi+EatcUTvK4g3F/4RLmcJyavgGGHfK+yyS3B1p zDMro2nfMDpB/2PSscpTK5kCQXBwV/L+nijVs0EHRHaTtv4EeGmzOGxcwqGwLUuvELS8 Pv+w== X-Gm-Message-State: AOJu0YxpiZwfdidYi7sZI5NeACLM7cj4fAomybukdX2OKl3mWaVnI3un JDAFWSEyAgmLPKXhvytMWlHMx/ox0wEjZiUkiICHJs4K644g4u8pwIP5 X-Gm-Gg: AR+sD135WeE0qXTm2dfY0ztjY0cz98LPfmQirQJUqirPbYCLRFzacf3/OJBArXjtI2S R/HfwE22cXhh37lHY0aZen1gF/Qj3a4oAwF06loKTAOjE5+2MgczDLO+Br3KgDRjcdHTOAsoQxG PxViN2Z/l6bKhxKGolfi8KsUaCI1Z4a1f3yqEHNnZo//5jNSW0UpAbWJJYhorUVhquHrjj2n6b9 hbkILNlnlZFIUAi6kNYu+POxpMSFbKukZCG03DZomg4k14epIAyvezJcAOO+6OOD1+I0wyIO15a +iQFklpJbboJi6CcB44Jkr/k3HSY5NQ+vIApueKG/cY/yFWNt0Z5ZuEN3xlUffp2zjcLrQ+ZP9s YIisph3yzckpLwdQD/+2fzOvYf7kCJ1di+wlVvdLuzoKX1AxpMBizytlNEztaX9bjaq00LPTCut Dp+xozdp5AZugERbQw9F9VK7wl+wh8/aV7E+bPB0nBox0NZ3MNT5XWclf6TewaONi02sn/dxd2p GWToO5fhzaqTRna+zCCGhtUrvvHMIFBadjAQqJJ8gu3ewJD X-Received: by 2002:a05:600d:117:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-49987ab4e1bmr60498825e9.7.1786721266512; Fri, 14 Aug 2026 08:27:46 -0700 (PDT) Received: from bdtpg (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499899afa39sm44054055e9.2.2026.08.14.08.27.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 08:27:46 -0700 (PDT) Date: Fri, 14 Aug 2026 15:27:44 +0000 From: Bertrand Drouvot To: Daniel Gustafsson Cc: PostgreSQL Hackers , Zsolt Parragi Subject: Re: Offline data checksum changes can cause incorrect checksum state on standbys Message-ID: References: <1C2BC974-44FA-487C-8A3B-8135A316A89B@yesql.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C2BC974-44FA-487C-8A3B-8135A316A89B@yesql.se> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Fri, Aug 14, 2026 at 03:59:06PM +0200, Daniel Gustafsson wrote: > running a cluster with mismatched data_checksums > settings across the nodes is not a supported mode of operation, and is already > documented to not work Thanks for feedback! The pre f19c0eccae96 pg_checksums documentation said: " When using a replication setup with tools which perform direct copies of relation file blocks (for example pg_rewind), enabling or disabling checksums can lead to page corruptions in the shape of incorrect checksums if the operation is not done consistently across all nodes. " I read that as a recommendation to stop and switch all nodes consistently, and as a warning about direct block-copy tools. That interpretation, together with the pre f19c0eccae96 behavior, is why v1 proposed keeping offline pg_checksums changes local. The intention was to preserve the previous behavior, not to introduce a new supported mode. I just realized that f19c0eccae96 explicitly changed the "Off-line Enabling of Checksums" documentation: " Data checksums are enabled or disabled at the full cluster level, and cannot be specified individually for databases or tables. " by: " Data checksums are enabled or disabled at the full cluster level, and cannot be specified individually for databases, tables or replicated cluster members. " while leaving the pg_checksums documentation quoted above unchanged. Depending on how the issue will be addressed, it might be worth changing this pg_checksums wording too? Looking forward to seeing your and Zsolt's proposals. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com