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 1rhp05-00DXqc-5l for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Mar 2024 10:59:53 +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 1rhp03-008xI3-LH for pgsql-bugs@arkaria.postgresql.org; Wed, 06 Mar 2024 10:59:52 +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.94.2) (envelope-from ) id 1rhp03-008xHv-C8 for pgsql-bugs@lists.postgresql.org; Wed, 06 Mar 2024 10:59:51 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rhozy-0034Uv-S7 for pgsql-bugs@lists.postgresql.org; Wed, 06 Mar 2024 10:59:50 +0000 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2d23114b19dso85121961fa.3 for ; Wed, 06 Mar 2024 02:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1709722786; x=1710327586; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ztUjU0hrKVotSIxTWNOYSFL7Kj5CfCHD6B0y7SP7t4g=; b=JpedJYHTDCmvW9KrW5/kbKmITVWganWiMgDVseiX8PkB7O6o0apWC2xVOX4alQjars VXC8fmtYcfHg+bQnzaiufTqx7ToRPKmKnliOXPXRmm9oOi0AqHzXWYeNVtxRNxAJVWHF 473oGMj/mSZhWDCQSq5CBZ9MKcDXZ+pExd8xc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709722786; x=1710327586; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ztUjU0hrKVotSIxTWNOYSFL7Kj5CfCHD6B0y7SP7t4g=; b=rjJxC207pzJLkajhUY+ljmacFyPnbpzN9/aPId4pSZGyTcST0nWgKwZoduee3G1VTt ZpXdYmXmUh8HHiOuQhNivthEUuBKS17e19aMeiqrwPmOUAZMnt9CvnYS1R+ru3whb7lf 8MsmGAp1zxVpVtFQjsAwMWYLXcD+DAaIPSSdiQFMh/YzatV6tfm/N1HkNvZQPiDL8xXp r+YN5M0oz0sxMXO8gzj5/H/R/mJ8f+I9ifEPWWxbYrvXqzfTlvfdkMl6/mU7iXEa8FmK eEq4si++dQFjLXEVYkNnzwVcB5+9W1HcYIiIIy4iTDjoPRbGqSenEMDGf0iQuyBa0qxV WtpA== X-Gm-Message-State: AOJu0YzMMqJWJmQL65Uq5UOBn05oliusVo2psZdDWumPlcKlbq7DUOUh NeW4LwJ9ucgzvQB0msQUapLkQmVcstcEE8ba9zRSDKjHJKIPFXJIf3cH0Q53XPc= X-Google-Smtp-Source: AGHT+IG4QKLT/K7yVXDvE+W7hwb1GuXCqOhlmJib0Jb0WFJDjWiEedfvEeFxaW57cNwosrU5uqMcqg== X-Received: by 2002:a2e:9b05:0:b0:2d2:748a:58a4 with SMTP id u5-20020a2e9b05000000b002d2748a58a4mr3349393lji.27.1709722785764; Wed, 06 Mar 2024 02:59:45 -0800 (PST) Received: from [10.0.0.75] (148.202.40.145.ftth.as8758.net. [145.40.202.148]) by smtp.gmail.com with ESMTPSA id bq9-20020a0568201a0900b005a0c5432815sm1572356oob.0.2024.03.06.02.59.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Mar 2024 02:59:45 -0800 (PST) Message-ID: Date: Wed, 6 Mar 2024 11:59:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: FSM Corruption (was: Could not read block at end of the relation) Content-Language: en-US To: Ronan Dunklau , Noah Misch , Michael Paquier Cc: pgsql-bugs References: <3609363.R56niFO833@aivenlaptop> <1958756.PYKUYFuaPT@aivenlaptop> From: =?UTF-8?Q?Patrick_St=c3=a4hlin?= In-Reply-To: <1958756.PYKUYFuaPT@aivenlaptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 3/6/24 10:31, Ronan Dunklau wrote: > Le mardi 5 mars 2024, 00:05:03 CET Noah Misch a écrit : >> I would guess this one is more risky from a performance perspective, since >> we'd be adding to a hotter path under RelationGetBufferForTuple(). Still, >> it's likely fine. > > I ended up implementing this in the attached patch. The idea is that we detect > if the FSM returns a page past the end of the relation, and ignore it. > In that case we will fallback through the extension mechanism. @@ -582,7 +583,17 @@ RelationGetBufferForTuple(Relation relation, Size len, * We have no cached target page, so ask the FSM for an initial * target. */ + nblocks = RelationGetNumberOfBlocks(relation); targetBlock = GetPageWithFreeSpace(relation, targetFreeSpace); I'd move the fetching of nblocks to after getting the targetBlock. This avoids extending the relation in the unlikely event of a FSM/relation extension in-between those two calls. Patrick