| От | Vik Fearing |
|---|---|
| Тема | Re: [BUGS] BUG #10823: Better REINDEX syntax. |
| Дата | |
| Msg-id | 53DB69DE.8040009@dalibo.com обсуждение исходный текст |
| Ответы |
Re: [BUGS] BUG #10823: Better REINDEX syntax.
|
| Список | pgsql-hackers |
On 07/30/2014 07:46 PM, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: >> On Wed, Jul 30, 2014 at 01:29:31PM -0400, Tom Lane wrote: >>> I don't find it all that odd. We should not be encouraging routine >>> database-wide reindexes. > >> Uh, do we encourage database-wide VACUUM FULL or CLUSTER, as we use them >> there with no parameter. Is there a reason REINDEX should be harder, >> and require a dummy argument to run? > > I believe that REINDEX on system catalogs carries a risk of deadlock > failures against other processes --- there was a recent example of that > in the mailing lists. VACUUM FULL has such risks too, but that's been > pretty well deprecated for many years. (I think CLUSTER is probably > relatively safe on this score because it's not going to think any system > catalogs are clustered.) > > If there were a variant of REINDEX that only hit user tables, I'd be fine > with making that easy to invoke. Here are two patches for this. The first one, reindex_user_tables.v1.patch, implements the variant that only hits user tables, as suggested by you. The second one, reindex_no_dbname.v1.patch, allows the three database-wide variants to omit the database name (voted for by Daniel Migowski, Bruce, and myself; voted against by you). This patch is to be applied on top of the first one. -- Vik
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера