Re: [ADMIN] reindexdb hangs
От | Alvaro Herrera |
---|---|
Тема | Re: [ADMIN] reindexdb hangs |
Дата | |
Msg-id | 20070829222341.GX7911@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [ADMIN] reindexdb hangs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [ADMIN] reindexdb hangs
|
Список | pgsql-hackers |
Tom Lane wrote: > > I examined cluster.c and it does seem to be missing a check too. I'm > > not sure where to add one though; the best choice would be the place > > where the list of rels is built, but that scans only pg_index, so it > > doesn't have access to the namespace of each rel. So one idea would be > > to get the pg_class row for each candidate, but that seems slow. > > Another idea would be to just add all the candidates and silently skip > > the temp indexes in cluster_rel. > > Yeah, an extra fetch of the pg_class row doesn't seem all that nice. > I think you'd want to check it in approximately the same two places > where pg_class_ownercheck() is applied (one for the 1-xact and one for > the multi-xact path). Actually, the 1-xact path does not need it, because the check is already elsewhere. We only need logic enough to skip temp tables silently while building the list in the multi-xact path. What this means is that very few people, if any, clusters temp tables; because as soon as you do, a plain CLUSTER command in another session errors out with alvherre=# cluster; ERROR: cannot cluster temporary tables of other sessions So, patch attached. > Are there any other commands to be worried about? I can't see any > besides VACUUM/ANALYZE, and those seem covered. I can't think of any. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Вложения
В списке pgsql-hackers по дате отправления: