Re: pgsql-server/src/backend catalog/index.c comma ...
От | Hiroshi Inoue |
---|---|
Тема | Re: pgsql-server/src/backend catalog/index.c comma ... |
Дата | |
Msg-id | 006101c37f23$ef4fc070$3d283ddb@PbgX обсуждение исходный текст |
Ответ на | Re: pgsql-server/src/backend catalog/index.c comma ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgsql-server/src/backend catalog/index.c comma ...
|
Список | pgsql-committers |
> "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
В списке pgsql-committers по дате отправления: