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 1qPRlx-00B2zS-E2 for pgsql-bugs@arkaria.postgresql.org; Fri, 28 Jul 2023 18:01:05 +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 1qPRlu-000CAD-VT for pgsql-bugs@arkaria.postgresql.org; Fri, 28 Jul 2023 18:01:02 +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 1qPRlu-000CA5-Mz for pgsql-bugs@lists.postgresql.org; Fri, 28 Jul 2023 18:01:02 +0000 Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qPRlr-00259q-Uk for pgsql-bugs@lists.postgresql.org; Fri, 28 Jul 2023 18:01:01 +0000 Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-686fc0d3c92so1363815b3a.0 for ; Fri, 28 Jul 2023 11:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690567259; x=1691172059; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=N4DcCl0Ixy5aC/TN2rYZMSh2Lx6b0vWlQFjfd/LkgBI=; b=aLAxnuWDeEL4iIRCTFEpCFNKV0vFHBPeVHASKD/WmH7SkxsnMd3QamxTvpKUsXRjwT KUcoHUNAVtXndmS4kc3qXFJqY2uPNuj+W+hZF7qHJwPneuVVUxaD2fnAYfQXVHHpJv5k jz0xqgzDUVeCYNl6y/1hU+syfjO/LuWFwZ7h+AX1fvobfp2qbwmvS5y3Gf5EhHe5DfCp tbwomzjP1N6QVjn1KE5ntnJ2AQUMBRwym/Fy8QlSl2SsgIFlNVb38Kae0spFkEFOXD3Q Q9FcaeX1UpJpW2j+IXMD7FpzFWpc2L4PzZ3hMoQLbGRBvPrdXdNoXF7EnwnCOLlsz8r8 qr5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690567259; x=1691172059; h=in-reply-to: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=N4DcCl0Ixy5aC/TN2rYZMSh2Lx6b0vWlQFjfd/LkgBI=; b=l/czSnpNGk9GrTL0nNw4wuEpJtyq/Spffe2VbtLDiTnuxHE1K8Kr5CQjaboOQnVkDr cGU7YOo7yw6A8gyZrO3DAX9AFbRiz+XuxfqRxqIh6Sp3qpSt2nuS+VxwLe8fp6QgY+CN JrrLg30mebP5oQjcrVpuzTMdT4sbt32yV+Y4XeRqVzZc17reipSy6HMo16h86kTIccKi rTSStDW6mrxgMQrVCWWso5O1Q6XZAJSCVE7kTYIkhdPBhWZBGG+PU1Dh0D1Gn1OrtWKI hN7toh/URVohv+EE7o0WxD86QdLOrUi2TSFlD9XFwYkCHIEgeIJNhnGGhvonhqWW+bOJ 4GGg== X-Gm-Message-State: ABy/qLaTyhKcWJ8hqGbSyvk969wKuEpbORNJsMlENoEXOxwWAuQW4t7U 8gmTnQLuJCNvuSL56cRzu5o= X-Google-Smtp-Source: APBJJlE4jgCTBShkWOpqVDIcguqZvsKT+ebjKQBdVDtMZ8KjnnW8eZGyd7gkHwRjKvklruuQXteQSQ== X-Received: by 2002:a05:6a00:1883:b0:666:b254:1c9c with SMTP id x3-20020a056a00188300b00666b2541c9cmr2743738pfh.27.1690567258961; Fri, 28 Jul 2023 11:00:58 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id c20-20020aa78e14000000b0064aea45b040sm3469396pfr.168.2023.07.28.11.00.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jul 2023 11:00:58 -0700 (PDT) Date: Fri, 28 Jul 2023 11:00:56 -0700 From: Nathan Bossart To: Michael Paquier Cc: Gurjeet Singh , Tom Lane , Richard =?iso-8859-1?Q?Vesel=FD?= , pgsql-bugs@lists.postgresql.org Subject: Re: Fwd: BUG #18016: REINDEX TABLE failure Message-ID: <20230728180056.GB3661419@nathanxps13> References: <1867443.1688912310@sss.pgh.pa.us> <20230726175000.GA3259285@nathanxps13> <20230727231441.GB3612597@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jul 28, 2023 at 10:50:50AM +0900, Michael Paquier wrote: > On Thu, Jul 27, 2023 at 04:14:41PM -0700, Nathan Bossart wrote: >> On Wed, Jul 26, 2023 at 06:43:18PM -0700, Gurjeet Singh wrote: >>> I felt the need for that paragraph, because it doesn't feel obvious to >>> me as to why we can't simply reindex the toast table as the first >>> thing in this function; the toast table reindex will trigger CCI, and >>> that'd be bad if done before RelationGetIndexList(). >> >> I see. I'd suggest referencing the comment above the function, but in >> general I do think having a comment about this is appropriate. > > + * This should be done after the suppression of the use of indexes (above), > + * because the recursive call to reindex_relation() below will invoke > + * CommandCounterIncrement(), which may prevent enumeration of the indexes > + * on the table. > > This does not explain the reason why this would prevent the creation > of a consistent index list fetched from the parent table, does it? > Would some indexes be missing from what should be reindexed? Or some > added unnecessarily? Would that be that an incorrect list? IIUC the issue is that something (e.g., VACUUM FULL, CLUSTER) might've just rebuilt the heap, so if we CCI'd before gathering the list of indexes, the new heap contents would become visible, and the indexes would be inconsistent with the heap. This is a problem when the relation in question is a system catalog that needs to be consulted to gather the list of indexes. To handle this, we avoid the CCI until after gathering the indexes so that the old heap contents appear valid and can be used as needed. Once that is done, we mark the indexes as pending-rebuild and do a CCI, at which point the indexes become inconsistent with the heap. This behavior appears to have been added by commit b9b8831. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com