> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > >> I'd ask the question the other way: why would it be a good > >> idea to allow > >> this in REINDEX TABLE and not in the other two cases? And > >> did it really > >> work? > > > Yes. I would revert your change. > > You didn't answer the first question: why's this a good idea? > It seems risky and
> of little value to try to support system > table reindexing without disabling system indexes. Why could you determine it ? Is PostgreSQL your system ? Because It is never of little value of cource, I supported it. I intended to support on-line REINDEX from the first, I first implemented REINDEX in standalone mode not in bootstrap(Jan's idea) mode. I also intended to support on-line reindexing nailed relations but I didn't have time to achive it. > Also, your assertion that it works doesn't convince me. That business > in reindex_table about doing two setRelhasindex() calls gave me the > willies. Why was that needed? The setRelhasIndex() has no meaning to other backends, i.e the false state is never visible to other backends. > "to keep consistency with WAL" isn't > enough commentary for code as strange as that. And having a > CommandCounterIncrement() that's executed in some cases and not others > is a recipe for bugs; we've been burnt by that before. The code you are referring is to reindex pg_class relation. The code has never active unless an #ifdef is defined. regards, Hiroshi Inoue ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
