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 1tsMuT-001EOb-9i for pgsql-general@arkaria.postgresql.org; Wed, 12 Mar 2025 14:18:13 +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 1tsMuR-00629a-73 for pgsql-general@arkaria.postgresql.org; Wed, 12 Mar 2025 14:18:11 +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 1tsMuQ-00626w-RT for pgsql-general@lists.postgresql.org; Wed, 12 Mar 2025 14:18:10 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tsMuO-002R2X-2k for pgsql-general@lists.postgresql.org; Wed, 12 Mar 2025 14:18:09 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 52CEI7OK1955104; Wed, 12 Mar 2025 10:18:07 -0400 From: Tom Lane To: Luca Ferrari cc: Artur Zakirov , pgsql-general Subject: Re: ERROR: could not read block 0 in file when creating an index out of a function In-reply-to: References: Comments: In-reply-to Luca Ferrari message dated "Wed, 12 Mar 2025 13:31:05 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1955102.1741789087.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Wed, 12 Mar 2025 10:18:07 -0400 Message-ID: <1955103.1741789087@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Luca Ferrari writes: > On Wed, Mar 12, 2025 at 12:54 PM Artur Zakirov wrote: >> In your case `base/357283/365810` file is a new index file. For some >> reason Postgres tries to read the new index. I suppose this is because >> during reading the table `t` within the function `f_t` it tries to >> access the new index. > Yeah, even if it is not clear to me why it is trying to read the index > that is under creation (i.e., not usable yet). Yeah, this has been reported before. While planning the "SELECT FROM tt" query within the function, the planner tries to access all the indexes of tt --- including the one that's only half-built. (Specifically, it wants to know the tree heights of all the btree indexes.) We've dismissed this as not being something we care to fix, because the argument that such a function is immutable is specious. And the case can't really happen without a function referencing the index's base table; for example, a query from another session can't see the uncommitted index at all. regards, tom lane