Re: Checking for missing heap/index files - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Checking for missing heap/index files
Date
Msg-id 510DF2D6-22AB-4741-8A08-26F48CC25644@enterprisedb.com
Whole thread Raw
In response to Checking for missing heap/index files  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Checking for missing heap/index files
List pgsql-hackers

> On Jun 8, 2022, at 5:45 AM, Bruce Momjian <bruce@momjian.us> wrote:
>
> Is this something anyone has even needed or had requested?

I might have put this in amcheck's verify_heapam() had there been an interface for it.  I vaguely recall wanting
somethinglike this, yes. 

As it stands, verify_heapam() may trigger mdread()'s "could not open file" or "could not read block" error, in the
courseof verifying the table.  There isn't an option in amcheck to just verify that the underlying files exist.  If
structf_smgr had a function for validating that all segment files exist, I may have added an option to amcheck (and the
pg_amcheckfrontend tool) to quickly look for missing files. 

Looking at smgr/md.c, it seems mdnblocks() is close to what we want, but it skips already opened segments "to avoid
redundantseeks".  Perhaps we'd want to add a function to f_smgr, say "smgr_allexist", to check for all segment files?
I'mnot sure how heavy-handed the corresponding mdallexist() function should be.  Should it close all open segments,
thenreopen and check the size of all of them by calling mdnblocks()?  That seems safer than merely asking the
filesystemif the file exists without verifying that it can be opened. 

If we made these changes, and added corresponding quick check options to amcheck and pg_amcheck, would that meet your
currentneeds?  The downside to using amcheck for this sort of thing is that we did not (and likely will not) back port
it. I have had several occasions to want this functionality recently, but the customers were on pre-v14 servers, so
thesetools were not available anyway. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Error from the foreign RDBMS on a foreign table I have no privilege on
Next
From: Peter Geoghegan
Date:
Subject: Re: BTMaxItemSize seems to be subtly incorrect