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 1rv6dI-009in7-F4 for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Apr 2024 02:27:17 +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 1rv6dH-008bNt-Ex for pgsql-bugs@arkaria.postgresql.org; Fri, 12 Apr 2024 02:27:15 +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 1rv6dH-008bNl-6j for pgsql-bugs@lists.postgresql.org; Fri, 12 Apr 2024 02:27:15 +0000 Received: from mail-yw1-x1134.google.com ([2607:f8b0:4864:20::1134]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rv6dE-000T84-Q8 for pgsql-bugs@lists.postgresql.org; Fri, 12 Apr 2024 02:27:14 +0000 Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-615053a5252so4081977b3.1 for ; Thu, 11 Apr 2024 19:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1712888831; x=1713493631; darn=lists.postgresql.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UfvA9S3jdS5f5KN3ywkRqg8e3/Xuq5H0bwSv6nNVq2I=; b=WmaO8i2z1w3bAEkcxw4EccjAgJWdYJirVj6+8t7mU5sGWRpQoWxTavG2eVzECPZJNG sKD8ihOQ42nWwxc9CRZrJlYnyqeWskEa8iYsWMvz2UdLrhafiTIwGhm0mBNIDvajuPtT fbj9lofTDYUKoBAgy5uLxwpc4xbmBze9WQlmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712888831; x=1713493631; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UfvA9S3jdS5f5KN3ywkRqg8e3/Xuq5H0bwSv6nNVq2I=; b=pPTUT+nVOeGlgbwF3h4o+CBmcSJbacdZgGy9syypq6Fr/76C7PH8wjvBLRID/IlfvN 1qDDGrorJ3LWjaD16vIsWLROdAiZ0y6P7biXxrk1aUM42bTAnkKFXPpMZWsJ3GceGUpv nKvcTkR6Xjs83OZXDamNQlMmIiPSwkCBh0Z24G9MKc0vErL6aWO/ngYwz1dpfHGMAQ7R TWoP+hA/A6MIBZDVFO0SjVcdEbJYHPAVpE94o07sQ+VhDa46jInnpqAS3h0ZbETo0CRd NJrDohSad9JzCnSncG55zyQkHgxp2k0SrQ8mbE407vhquVp+oL5R15VxvEH/z1JOX+gx nx5w== X-Forwarded-Encrypted: i=1; AJvYcCWHgn5KDbP03OSd0x571Fg09rlpBJG6e92QgJcgwOwmdTcmHhBQSUeJsiXIHfCl3K/leOCB5fFepenPXfylYWMyPyAMkLZL9SgLeGfeEW9o X-Gm-Message-State: AOJu0YxKg4mUpBL5kvBeXWTXNijAtKBnv6TsLLjWZO/miTXLhene90Xf MXdSHa2SopJRLEVQrIO2lykG8B8IdxgXFjBYnLFYB3/aPz4XtzD4/j1HaP5Evw== X-Google-Smtp-Source: AGHT+IGXJ4vBGnE3XvelRXaOWpxb60849WH91Ol9Nof5RKL1/tyYngjIdx8B2SfW6id5s8EiEs4vvQ== X-Received: by 2002:a0d:ca57:0:b0:617:fdc2:ff0b with SMTP id m84-20020a0dca57000000b00617fdc2ff0bmr1344554ywd.5.1712888830921; Thu, 11 Apr 2024 19:27:10 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id z186-20020a0dd7c3000000b006158165c606sm615677ywd.136.2024.04.11.19.27.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2024 19:27:10 -0700 (PDT) Date: Thu, 11 Apr 2024 19:27:08 -0700 From: Noah Misch To: Peter Geoghegan Cc: Ronan Dunklau , Michael Paquier , pgsql-bugs Subject: Re: FSM Corruption (was: Could not read block at end of the relation) Message-ID: <20240412022708.d6@rfd.leadboat.com> References: <1970118.yKVeVyVuyW@aivenlaptop> <20240312220807.05.nmisch@google.com> <3225659.5fSG56mABF@aivenlaptop> <20240313165523.6a@rfd.leadboat.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.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Apr 11, 2024 at 12:01:09PM -0400, Peter Geoghegan wrote: > On Wed, Mar 13, 2024 at 12:55 PM Noah Misch wrote: > > That's a reasonable thing to worry about. We could do wrong by trying too > > hard to use an FSM slot, and we could do wrong by not trying hard enough. > > Although it's not related to the problem you're working on, it seems > like a good opportunity to bring up a concern about the FSM that I > don't believe was discussed at any point in the past few years: I > wonder if the way that fsm_search_avail() sometimes updates > fsmpage->fp_next_slot with only a shared lock on the page could cause > problems. At the very least, it's weird that we allow it. fsm_search_avail() treats an out-of-range fp_next_slot like zero, so I'm not seeing a correctness issue. I bet changing it under an exclusive lock wouldn't deliver better-optimized searches to an extent that pays for the synchronization overhead, but it might.