public inbox for [email protected]  

help / color / mirror / Atom feed

From: Frits Hoogland <[email protected]>
To: Tom Lane <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: [email protected]
Subject: Re: The ability of postgres to determine loss of files of the main fork
Date: Wed, 1 Oct 2025 14:02:50 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAJ7c6TMYvYBQpgv8k+4QnajqPcroOzrj7d3snBBTKX4tHQfVYw@mail.gmail.com>
	<[email protected]>

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 <[email protected]> wrote:
> 
> Aleksander Alekseev <[email protected]> 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

view thread (21+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: The ability of postgres to determine loss of files of the main fork
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox