From: Tom Lane <tgl@sss.pgh.pa.us>
To: Aleksander Alekseev <aleksander@tigerdata.com>
cc: Frits Hoogland <frits.hoogland@gmail.com>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: The ability of postgres to determine loss of files of the main
 fork
In-reply-to: 
 <CAJ7c6TMYvYBQpgv8k+4QnajqPcroOzrj7d3snBBTKX4tHQfVYw@mail.gmail.com>
References: <013D63E2-5D75-492E-85FF-1D5CC0148C82@gmail.com>
 <CAJ7c6TMYvYBQpgv8k+4QnajqPcroOzrj7d3snBBTKX4tHQfVYw@mail.gmail.com>
Comments: In-reply-to Aleksander Alekseev <aleksander@tigerdata.com>
	message dated "Tue, 30 Sep 2025 18:55:16 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <499685.1759250489.1@sss.pgh.pa.us>
Date: Tue, 30 Sep 2025 12:41:29 -0400
Message-ID: <499686.1759250489@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/499686.1759250489%40sss.pgh.pa.us>
Precedence: bulk

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