On 8/24/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Steven Flatt" <[EMAIL PROTECTED]> writes: > > 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). > > Where in the world did you get that idea?
Maybe that's what I was *hoping* the behaviour would be. :) >From the docs: "REINDEX locks out writes but not reads of the index's parent table." "It also takes an exclusive lock on the specific index being processed..." I believe those two statements imply that reads of the parent table don't take any lock whatsoever on the index being processed, i.e. they ignore it. If we had a REINDEX CONCURRENTLY it might work that way. A normal > REINDEX cannot "mark" anything because it runs within a single > transaction; there is no way that it can emit any catalog changes > that will be visible before it's over. > ... but I understand this difficulty. So, can we simply trust what's in pg_class.relpages and ignore looking directly at the index? This is a fairly serious concern for us, that reindex is blocking all readers of the parent table. Thanks, Steve
