From: | Frits Hoogland <frits(dot)hoogland(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: The ability of postgres to determine loss of files of the main fork |
Date: | 2025-10-01 12:02:50 |
Message-ID: | E769DCEF-8D50-4C97-86F7-52491638DD4F@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Aleksander Alekseev <aleksander(at)tigerdata(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2025-10-01 12:05:53 | Re: The ability of postgres to determine loss of files of the main fork |
Previous Message | Frits Hoogland | 2025-10-01 11:58:54 | Re: The ability of postgres to determine loss of files of the main fork |