Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > The change on tcop/utility.c seems to inhibit the execution
> > of REINDEX of system indexes under postmaster which I allowed
> > except some system indexes in 7.1.
>
> That strikes me as a fairly dangerous idea. Do you really
> believe it's safe? Also, why would it be safe to allow reindex
> at the table level and not at the index level, which is what
> the code did before I touched it?
REINDEX uses the relfilenode mechanism since 7.1 which
lets the replacement of index files be under transactional
control. I think it's safe enough. One thing I had to worry
about REINDEX on system indexes is how to tell that the
target index mustn't be used during the REINDEX operation.
Turning off the relhasindex column in pg_class tells
PG system that the indexes are unavailable now. It was
implemented by me before 7.0. I didn't provided the
way to inactivate indexes individually however.
>
> > Especially setNewRelfilenode() unlinks the pg_internal.init
> > file in case the relation is nailed.
>
> Probably with this change I'm planning, it'll be necessary to unlink
> pg_internal.init for any system relation, not only nailed ones.
> Thanks for pointing that out.
What I meant was to confirm if it's really reliable.
Currently e.g. the failure of rename of temporary
init file to pg_internal.init isn't fatal but it
may be fatal if we include many relcache info in
the pg_internal.init file.
regards,
Hiroshi Inoue
