> "Hiroshi Inoue" <inoue@tpf.co.jp> 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
