Re: The ability of postgres to determine loss of files of the main fork - Mailing list pgsql-hackers

From Frits Hoogland
Subject Re: The ability of postgres to determine loss of files of the main fork
Date
Msg-id E769DCEF-8D50-4C97-86F7-52491638DD4F@gmail.com
Whole thread Raw
In response to Re: The ability of postgres to determine loss of files of the main fork  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thank you for your answer Tom,

As pointed out in another thread of this topic: using the heapallindexed option, it is 
not possible to detect that the table has missing segments and thus missing data.
What it will detect is if the index is missing data that is existing in the table, it validates
table->index.

Frits Hoogland




On 30 Sep 2025, at 18:41, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Aleksander Alekseev <aleksander@tigerdata.com> writes:
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.

... 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.

As Frits mentioned, neither of those actions will really notice if a
table has been truncated via loss of a segment.

However, I think the requested functionality already exists via
contrib/amcheck (see the heapallindexed option).  The user does have
to make a decision which index to check with, but I think that'd be
required anyway --- as you say, there isn't necessarily a primary key.

regards, tom lane

pgsql-hackers by date:

Previous
From: Frits Hoogland
Date:
Subject: Re: The ability of postgres to determine loss of files of the main fork
Next
From: Jakub Wartak
Date:
Subject: Re: The ability of postgres to determine loss of files of the main fork