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 1v65Od-00GZFP-Lb for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Oct 2025 10:58:19 +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 1v65Ob-00Fz3U-Cg for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Oct 2025 10:58:18 +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 1v65Ob-00Fz2m-2J for pgsql-hackers@lists.postgresql.org; Tue, 07 Oct 2025 10:58:18 +0000 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v65OY-000Tke-0E for pgsql-hackers@lists.postgresql.org; Tue, 07 Oct 2025 10:58:16 +0000 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-36a6a397477so61002931fa.3 for ; Tue, 07 Oct 2025 03:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1759834693; x=1760439493; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O2eRzy/vHqSLdDdSJa3OO/XUs6FA893Do3vM4ADdB3g=; b=cvnNyc2DQB+tg3t9MYg941m4Cr3ItWUVwBnTPi6TC2M0I5Nd7CgQoN7woA2IXps4kr 8oUfX11p853nRehfaM6iUtmz30mE6XpiY75qV6MMiAsD6CGVvHJw47sJ5Y083xrRRCzn 12S+Y1MKfd2Cqszw/PtH5RmksfCiIJLQeOjf6gj4eJBJfYi318nkad0QfGWM9yZCb0An dwAr5skzwvKKIpaNO7XWyvsd2847DOOWsvZ1mviT7+mp31Fum11H4vFSljUz1jwEpcvZ gwj43YMYmT+m1hQB+gYIFmjxNhmtTJdAbTzXqgYXtSOjYqgXFoQI6BtjO8cC+tnSu5y6 gmNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759834693; x=1760439493; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=O2eRzy/vHqSLdDdSJa3OO/XUs6FA893Do3vM4ADdB3g=; b=EVO1STptF58P1niP5XEvOfIY+p9dbegg5fr29xUYbXbR2eeVmVxDNQGgvdPo9OMUcj HQj7HdgMpcdQPhAEIWi8hKbbRXe+7PetMjs5WFNYHV+t1/ZSPECI7l1OKVar3MC2ZYDJ yvPYQr5J5++Uv0DWtCscawpquFyh2/CWM3KaBe0hgI/e9HEtF7r2z8B6YCf/GeonVbda s1u+LX3fzon6QkAH7dRO9KD3Keg/8TrZ7wU4KpyJaiK3ar9CKDLUIl7mdjvcDkmuBa9B DLr+EgbV6C9kAd5prPMpaiWA0SCQOYXLuTrR/LxQjsvflGQrydcmdl5H1HPwMlQiJ5+8 EcTA== X-Forwarded-Encrypted: i=1; AJvYcCWr56LTYdRcmTox8JKCRGdSLolqZLcMVnOZb0JxgKqgAxfe1FSuDRB8nI8O3sXtFqKJrQXn8Q4IgxgshqOj@lists.postgresql.org X-Gm-Message-State: AOJu0Yyo/yTpirFYGh5gYDg1li8PrI1tw+wtNfxxizjZ/ziAulzvz5NB e7qK2PVsoc2QOuv8tUJc75JiXgBmdj4sQbKcfPx53+i3Qrw4TRu/2PWhAUMWHydgBfyS9gLmoTj B6P4Ex2HwNNCtur/f2h+gIt21kRCSZXOojPCuU1VhRE5SfQl3Avk= X-Gm-Gg: ASbGnct0ixsFDVViDAxcPaLa4zvE+3CQ1MwNeU+0DY0Y1GLJLKA2F7ik2VV4x1pW1B9 JDvi0d1Gtzgm+i9J8SzWp92BvPDdmOVwiDMMSAMf5Wk31sYOiCe8XEZyRRxswjwGh7ti7ge6whU T5mDisMXhU5Kb8pSOoZa9bwljvMkd9Z6PhQcyOf1v9108LEGNR9ELo4INLf8feP5PVZCtRIJgs6 PTN62rZjkwDfW69z/cqcVGAZuAsID5u X-Google-Smtp-Source: AGHT+IGSjyry06cOALg/y2yN54DoWBywmGr8sVOuVbfi8lWf+vAXIekaIfbBrjDKLgO1D61u69P0IOaszlxkgnrq65s= X-Received: by 2002:a05:651c:892:b0:36a:1e4a:a3b9 with SMTP id 38308e7fff4ca-374c38499f8mr53287111fa.43.1759834693217; Tue, 07 Oct 2025 03:58:13 -0700 (PDT) MIME-Version: 1.0 References: <013D63E2-5D75-492E-85FF-1D5CC0148C82@gmail.com> <499686.1759250489@sss.pgh.pa.us> <68dcd1f2.df0a0220.3300c0.f7af@mx.google.com> <68dd1b79.170a0220.3c4175.198f@mx.google.com> <946a9fd4468f8d72aa7629a51a6349caf35e8a50.camel@cybertec.at> In-Reply-To: <946a9fd4468f8d72aa7629a51a6349caf35e8a50.camel@cybertec.at> From: Jakub Wartak Date: Tue, 7 Oct 2025 12:57:43 +0200 X-Gm-Features: AS18NWBHBBivLytqzXSPq0Q5mjIhe_o41_zNCUMIZDKVOybBRWRAF7av3iysy5M Message-ID: Subject: Re: The ability of postgres to determine loss of files of the main fork To: Laurenz Albe Cc: Michael Banck , Aleksander Alekseev , pgsql-hackers@lists.postgresql.org, Tom Lane , Frits Hoogland Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Oct 6, 2025 at 2:07=E2=80=AFPM Laurenz Albe wrote: > > On Mon, 2025-10-06 at 11:19 +0200, Jakub Wartak wrote: > > Anyway, I do not know if opening all the files on startup (or just > > crash-recovery?) is the proper way > > I am not sure if you understand the problem at hand: how can you > tell that a segment of a relation is missing? You have to know that > there should be a file before you can try to open it. I'm pretty aware that PG doesnt track the relation segment count, but possibly it should as without that nasty stuff can happen. Then the discussion was mostly on how practical it would be to just open all files on big DBs during startup (if we know them in advance), but it is just one of the ideas I suspect, I've just checked those timings out of curiosity. Anyway there's also a referenced earlier idea for single file relation model by Thomas. Another fun-fact: see READ_ONLY_OPEN_DELAYED details in Oracle. -J.