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
