On mið, 2006-12-13 at 11:05 +0100, Csaba Nagy wrote: > > Yeah, we could add defenses one by one for the cases we could think of, > > but I'd never feel very secure that we'd covered them all. > > What you all forget in this discussion is that reindexing concurrently > would have to be a highly administrative task, controlled by the DB > admin... so whoever has a big index to be reindexed can schedule it so > that no other schema changes occur to the table until the reindex is > finished. well, if this is a command that would nly be made manually by an administrator, why do we need a separate command for this. the DBA can just create a new index concurrently, and then perform the DROP and rename in a transaction whenever he thinks it is safe to take the exclusive lock needed for a short while. the only functionality missing compared to a REINDEX CONCURRENTLY, is the handling of a PRIMARY key constraint linked to the index while this happens, but that seems a much simpler problem to solve separately. gnari
