Re: [ADMIN] reindexdb hangs - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [ADMIN] reindexdb hangs
Date
Msg-id 20070829222341.GX7911@alvh.no-ip.org
Whole thread Raw
In response to Re: [ADMIN] reindexdb hangs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [ADMIN] reindexdb hangs  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: int8 & INT64_IS_BUSTED
Next
From: Tom Lane
Date:
Subject: Re: [DOCS] Contrib modules documentation online