Re: pgsql-server/src/backend catalog/index.c comma ...
От | Tom Lane |
---|---|
Тема | Re: pgsql-server/src/backend catalog/index.c comma ... |
Дата | |
Msg-id | 24200.1064072252@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server/src/backend catalog/index.c comma ... ("Hiroshi Inoue" <inoue@tpf.co.jp>) |
Ответы |
Re: pgsql-server/src/backend catalog/index.c comma ...
|
Список | pgsql-committers |
"Hiroshi Inoue" <inoue@tpf.co.jp> writes: > Why could you determine it ? Is PostgreSQL your system ? Well, if you prefer, we can have a discussion and vote about it on pghackers. But you have not answered my questions. Why was the code set up to allow live reindexing of system tables via REINDEX TABLE, but not via REINDEX INDEX or REINDEX DATABASE? It seems to me that those three cases ought to work equally well or badly. Let's remove the restriction from all three, if it's not needed. >> 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. Then why bother? I agree that it's probably not needed for other backends --- since you have an exclusive lock on the table, nobody else should be trying to examine it. But then why do it at all? The only thing you need is to force IsIgnoringSystemIndexes true locally, which would seem to me a much more secure way of proceeding. The goal that I am trying to accomplish here is to make the reindexing code more visibly safe and correct. I'm not convinced that we still need live-reindexing capability in 7.4 (I think the btree space recycling code solves the problem better). But I'm happy to leave it in if these other questions can be addressed. regards, tom lane
В списке pgsql-committers по дате отправления: