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 1v3chW-000z9a-44 for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Sep 2025 15:55:38 +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 1v3chS-00Avh5-Nk for pgsql-hackers@arkaria.postgresql.org; Tue, 30 Sep 2025 15:55:35 +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 1v3chS-00Avgs-DH for pgsql-hackers@lists.postgresql.org; Tue, 30 Sep 2025 15:55:35 +0000 Received: from mail-oa1-x2f.google.com ([2001:4860:4864:20::2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v3chQ-000j2B-1M for pgsql-hackers@lists.postgresql.org; Tue, 30 Sep 2025 15:55:33 +0000 Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-36ce5686d75so3541730fac.3 for ; Tue, 30 Sep 2025 08:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tigerdata.com; s=google; t=1759247727; x=1759852527; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t4BR3km3zlwLBdM8idBwpAXEgWdZMU5pME6Uukpu8qM=; b=NX0LCKc5CPkzLTKfbsi8YBRrYfdaQSb2ERGXk2MFHfV+0YuMevLcoStUqO0/v/jjoF x/veAXap54aZVYAoNpak9Br79iTiphP6/Bh/MrXT4TXDCtxNq/LvYNcA1WthS0vO1Abv ha/X9WU0ZAr+vpnkoXL59pbJj/EInSvPDc9bp1HhwqnzmLDHzG6HwIUUXAAlypL/Nn6s vEJjDpx9rJOiZuz8qEw863F6dzlCEUffg0rXX2GbI7+NArvdu0InHpKswHEXLgYpvwYo JoYK0EJ7x4Bu7//KKCNCLFKeQ0NlHkfshW/bYG+niOOugKHuzaWF3D59s6yvel8aTEWz AIow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759247727; x=1759852527; h=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=t4BR3km3zlwLBdM8idBwpAXEgWdZMU5pME6Uukpu8qM=; b=vlEFMN2b0q/V86qkCrPhux4H9HfvvHuxPqKKZj8rVvVSuc714V52VAAqsZXSNUOoOt BN/4ne6P7d4IsHO4OD1r0EAqLGIp8vjbrUsEB9ejNmpAXJFuiODcorxeR2tgmE4HUVxY 92QCDbhiW+QrWgKzbOhZnkVWngGLIezimzrxKOnLtAYiFerOuytjgYNE+1FHs+cV9KrL wqLh+PQSgrxb2svMaR8IZqPlAALPrfFvU76xcxsylgqa15a+UVeCX5+zTu/pouoUBKgi vsHg6R1fqCJnFdT0Lu4B4BIWwjvVscCQ+BEG8eykmfDyfqJArbad7En7UhSFtJtyR4w1 Y7Xg== X-Gm-Message-State: AOJu0YywYdLD6rHl/K8qY86B/Qwyv/VFSfnZoijsVeREH5A+Z6bn8kJJ hVIY3LyOWrvlCc9zw2wvI6gIV3z1qvxiWqMbMDZCx2cA/8sMeDaS1tX9NyUo0SChZgmMVgsGvV3 eFUr7HZ1IJnQV5Qea4GX+pjwBzQrXcxX7iLIJcUoPMrRdH3UE9qElxpyZBw== X-Gm-Gg: ASbGncuTa2OnEQQZV7Fw22WhEozYNljhZoyYDtvaSOj686YJoYds1l0NpfLyiIG2dA4 +Nt73RTSEvQMV8vodaS9CtSiPk8SKx/D8aj0D13NEnogjQgtSnHddfUU9JFOrDIy2EkXaO1X2W4 KDhAh2PfXYIGEGjVOKOfWGZepZdIhqHBazKJy07U+y6MRZ4zRTzWXyug/EVt72bHJU+R1ddV1nA rDfbNRMX7MYgLuB/4TSsku1JlSSOLcWJ7aOG73JW2Y= X-Google-Smtp-Source: AGHT+IGhss4bjpkf3vmoIvY17W9mZv1txCNmrIls1b3GEBHHWSGETLG9QCooIG04+80+/0J9PpPsVqAkEqGWiXuM9s8= X-Received: by 2002:a05:6870:1807:b0:35e:59ce:6c26 with SMTP id 586e51a60fabf-36b0e595470mr6541313fac.40.1759247727276; Tue, 30 Sep 2025 08:55:27 -0700 (PDT) MIME-Version: 1.0 References: <013D63E2-5D75-492E-85FF-1D5CC0148C82@gmail.com> In-Reply-To: <013D63E2-5D75-492E-85FF-1D5CC0148C82@gmail.com> From: Aleksander Alekseev Date: Tue, 30 Sep 2025 18:55:16 +0300 X-Gm-Features: AS18NWB-plzn-pveeCvqOmuAVKdNqmAvbbJVOnbW2vUfcVcJ_GeAvW4T4TOaWRI Message-ID: Subject: Re: The ability of postgres to determine loss of files of the main fork To: Frits Hoogland Cc: pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Frits, > Therefore, I would like to request an enhancement: add an option to > verify_heapam() that causes the primary key index to be scanned and makes > sure that all line pointers in the index point to existing tuples. I'm a bit puzzled by your emphasis on primary keys. In Postgres it is legal to have tables without PKs, indexes, or even columns: =# create table my_table(); =# select * from my_table; To clarify, are you proposing not to check such tables? > An alternative might be to track the number of segments of a relation in > pg_class, but that may be difficult to make crash-safe. Hm... the fact that we have a segment on disk doesn't mean it is not empty or not corrupted. Let's say we will add a check you are proposing. The next person will complain that we don't check the size of the segments. The next one - about the fact that we don't verify checksums. So IMO there is little value in adding a check for the existence of the segments for a single table. And the *real* check will not differ much from something like SELECT * FROM my_table, or from making a complete backup of the database. -- Best regards, Aleksander Alekseev