Re: The ability of postgres to determine loss of files of the main fork
От | Frits Hoogland |
---|---|
Тема | Re: The ability of postgres to determine loss of files of the main fork |
Дата | |
Msg-id | E769DCEF-8D50-4C97-86F7-52491638DD4F@gmail.com обсуждение исходный текст |
Ответ на | Re: The ability of postgres to determine loss of files of the main fork (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: