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

From Tom Lane
Subject Re: The ability of postgres to determine loss of files of the main fork
Date
Msg-id 499686.1759250489@sss.pgh.pa.us
Whole thread Raw
In response to Re: The ability of postgres to determine loss of files of the main fork  (Aleksander Alekseev <aleksander@tigerdata.com>)
Responses Re: The ability of postgres to determine loss of files of the main fork
Re: The ability of postgres to determine loss of files of the main fork
List pgsql-hackers
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: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: Srinath Reddy Sadipiralla
Date:
Subject: Re: [PATCH] Fix pg_rewind false positives caused by shutdown-only WAL