Tom Lane wrote: > > The fly in the ointment is that after collecting the pg_index definition > of the index, plancat.c also wants to know how big it is --- it calls > RelationGetNumberOfBlocks. And that absolutely does look at the > physical storage, which means it absolutely is unsafe to do in parallel > with a REINDEX that will be dropping the old physical storage at some > point.
A suggestion that seems a bit like a leap backwards in time - maybe just use the pg_class.relpages entry for the index size?
Just throwing this out there (looking from a higher level)...
Why do we even need to consider calling RelationGetNumberOfBlocks or looking at the pg_class.relpages entry? My understanding of the expected behaviour is that while a reindex is happening, all queries run against the parent table are planned as though the index isn't there ( i.e. it's unusable). This may/will result in sub-optimal query plans, but the point is that reindex never blocks readers. Not sure if from an implementation standpoint it's easy to mark an index as "being reindexed" in which case the planner should just skip it.
