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 1x5ntX-000HlY-13 for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Sep 2026 17:21:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1x5ntV-00A4gY-0R for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Sep 2026 17:21:33 +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.96) (envelope-from ) id 1x5ntU-00A4gP-2d for pgsql-hackers@lists.postgresql.org; Sun, 13 Sep 2026 17:21:32 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1x5ntP-00000000Cm4-20Ks for pgsql-hackers@postgresql.org; Sun, 13 Sep 2026 17:21:31 +0000 Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-38ea87caafeso2516640a91.3 for ; Sun, 13 Sep 2026 10:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1789320086; x=1789924886; darn=postgresql.org; h=user-agent:in-reply-to:content-transfer-encoding :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=BOiJmpNM1ub8Q3K8H2o3H5CA4MrsTrmuGvatjvkxT/w=; b=F8/djzcs/KIhPkdvr+gyPKQDs28V28D5Hsr6M0hLVSPTxzEqI5Y6ZVF2/T5l7Rjr7+ YFyLn42j54tAyc7XVotjFSSBDzCY/1e9tUCjYh9XTNKjVIuOdFQNCyT/VOTRi87yIWbC +BdA7yq7kfuRxA9tQSdp4rN68OoQqPBbDkFQk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789320086; x=1789924886; h=user-agent:in-reply-to:content-transfer-encoding :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=BOiJmpNM1ub8Q3K8H2o3H5CA4MrsTrmuGvatjvkxT/w=; b=jgbcaWuRXqAW4LSYJ6I3aRX94iCveZCAgiCN3Wsgeywonu591DweqdZqGalyAyRH6I wtWcyJSRt+fK5kI+xX53iYeUz0zLiPm2yHoeM38xCZwzvhlPzGxCIUQ9KRSRKxBZw99o BitWlEYFCdxbkOwQ5iBr07WlHQEfYAzOmaju+GJwVSZuNz0uocmMdYokB4O5MoM1Ztmi QNQLaPFo6GtGk6KrXyv/gYAEIPrNyCXHhn9AK+6hGmHE+PlqEuCFAHr4TfP2Z3B9FCcR TDZLYNV0n6luT7YhL4UI6iUJicxlTFVAhSiNU6IyRAUbfhQEdyCH3Khc3Il6yooJbb6Y qHeA== X-Forwarded-Encrypted: i=1; AKwUvBxH8XUD7H+MYTkdO3pCSw6xrOn3DbNZckVYdeXk7YlG18fu3J+zNu7u3Znk7QfE3OWfN44wzvA8K+RXN/d8@postgresql.org X-Gm-Message-State: AFuF++k0dIz9fztnJLqJp3q/6JXisjuwahWFcyV+f3Jhil1iTSo/RaLl 6D1fHPDyOm9bNGRSoJJ87400EELH+CMCCtXNlXxv5fRytVXoYTpGY2J8EJzj/ciwnYmE3Np7yLp zqxY2zw== X-Gm-Gg: AYBFou3BIAGxosPc9Z6Lahp+acVaQW0d8JC2gkUPNh4MDsMaTBE+eSJI1SMhIsS8gLV 6XoEriW1XZzN46HOMuZnpM2m7EMV8vDIvF86wT5TLmFknaEMRftpvXZj8R5CqWS1BN7dgZNmYUW Rx7Xy2yMKRyEuJowf2XoWJeSq8t7IkaV9JxSY8vk8wb9INyVu4yAyZnut/hKuYfvEIGUdI4I4hy GpH5m7vmL5kt3RrBAevG3Ptres+R3eCbkbgIawzzswxyy6pyh1mh7g14qJNHQxlBSeXYcNZjk86 gn9k9NYAOnlJTiKYRYEsbnNI3vR5BENpyfnIuc5dTex/TXypBQvVqPIH/jxGW1NKuN/1jWeAMh9 kqlgY9ciAgqUrO1DXh5qV19dVA2ejCFnnWZ6Yzz1hv2J64KIDzt2jA93ebsfZhOG5ljEvbr6T1I Wj5ENn1ncH8nz9uo+id0seTDcox83oii9yiVncw5d9e6N9Dpl99Ao6/pIQDj9mbiohMxoytfQ4s FVWOtJAAsP4X+lYrWfFVAyczEEkieE= X-Received: by 2002:a17:90a:fc48:b0:39a:e983:d4bd with SMTP id 98e67ed59e1d1-39d9c3527b5mr23585318a91.24.1789320085745; Sun, 13 Sep 2026 10:21:25 -0700 (PDT) Received: from microsoft.com (c-73-15-160-255.hsd1.ca.comcast.net. [73.15.160.255]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-14365a598aasm19061260c88.1.2026.09.13.10.21.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Sep 2026 10:21:25 -0700 (PDT) Date: Sun, 13 Sep 2026 10:21:23 -0700 From: Noah Misch To: Alexander Korotkov Cc: Melanie Plageman , Alexey Makhmutov , Andrey Borodin , pgsql-hackers@postgresql.org Subject: Re: Two issues leading to discrepancies in FSM data on the standby server Message-ID: <20260913172123.89.noahmisch@microsoft.com> References: <596c4f1c-f966-4512-b9c9-dd8fbcaf0928@postgrespro.ru> <6A6138F4-8D6F-463D-9ECC-38C0881308FE@yandex-team.ru> <60b79f39-69e5-4c73-a708-6ef1fd5e7980@postgrespro.ru> <20260901211837.f6.noahmisch@microsoft.com> <20260912200540.1b.noahmisch@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.3.0 (2026-01-25) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Sep 13, 2026 at 03:10:58PM +0300, Alexander Korotkov wrote: > On Sat, Sep 12, 2026 at 11:05 PM Noah Misch wrote: > > On Mon, Sep 07, 2026 at 06:22:22PM +0300, Alexander Korotkov wrote: > > > 0002 is patch for FSM readme to highlight this aspect > > > > > > I'm going to push (and backpatch) 0001. 0002 needs review. > > > > > Subject: [PATCH v1 2/2] Say in the FSM README why its hint writes still need > > > full page images > > > > > +That RBM_ZERO_ON_ERROR is a property of this directory, not of the FSM fork > > > +itself. The files themselves are ordinary relation files, and plenty of code > > > +outside freespace.c reads them and does verify checksums: > > > +RelationCopyStorage(), which ALTER TABLE ... SET TABLESPACE runs over every > > > +fork; the read stream in RelationCopyStorageUsingBuffer(), used by > > > +CREATE DATABASE ... STRATEGY = wal_log; and the checksum verification in base > > > +backups and in pg_checksums. The last two are the reason this cannot simply be > > > +relaxed: an external verification tool has no way to tell a tear that we > > > +consider harmless from one caused by failing storage, so making it accept > > > +the former blinds it to the latter. > > > > One could relax the "last two" by having those tools skip checksum > > verification for *_fsm files, so let's not claim it's infeasible. It's true > > that this could miss failing-storage evidence that coincidentally landed in > > FSM, but accepting that could be the right thing someday. Other than that, I > > agree with this README change. Thanks. > > I've corrected that paragraph. I'm going to push this to master if no > objections. > +That RBM_ZERO_ON_ERROR is a property of this directory, not of the FSM fork > +itself. The files themselves are ordinary relation files, and plenty of code > +outside freespace.c reads them and does verify checksums: > +RelationCopyStorage(), which ALTER TABLE ... SET TABLESPACE runs over every > +fork; the read stream in RelationCopyStorageUsingBuffer(), used by > +CREATE DATABASE ... STRATEGY = wal_log; and the checksum verification in base > +backups and in pg_checksums. The last two could instead be taught to skip > +*_fsm files, and that may be the right call someday. The cost would be that > +a tool told to ignore a tear in the FSM can no longer report one caused by > +failing storage. Today they do verify, so what we write here has to be > +valid. I'd handle the last sentences differently, yielding a paragraph like this: That RBM_ZERO_ON_ERROR is a property of this directory, not of the FSM fork itself. The files themselves are ordinary relation files, and plenty of code outside freespace.c reads them and does verify checksums: RelationCopyStorage(), which ALTER TABLE ... SET TABLESPACE runs over every fork; the read stream in RelationCopyStorageUsingBuffer(), used by CREATE DATABASE ... STRATEGY = wal_log; and the checksum verification in base backups and in pg_checksums. The alternative would be all such code skipping checksum validation of *_fsm files, and that may be the right call someday. Today they do verify, so what we write here has to be valid.