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

From Alvaro Herrera
Subject Re: [ADMIN] reindexdb hangs
Date
Msg-id 20070825222150.GU31461@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:
> "dx k9" <bitsandbytes88@hotmail.com> writes:
> > [ stuck reindex ]
> > It turns out it was a temporary database and temporary table, that just
> > wasn't there maybe it thought it was there from some type of snapshot then
> > the next minute it was gone.
>
> Hmm, there is not any filter in ReindexDatabase() to exclude temp tables
> of other backends, but it sure seems like there needs to be.  CLUSTER
> might have the same issue.  I think we fixed this in VACUUM long ago,
> but we need to check the other commands that grovel over all of a database.

Was this ever fixed?  I think it wasn't, because I don't see any check
in ReindexDatabase.  Here is a patch to add one.

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.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Attachment

pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: [WIP PATCH] Lazily assign xids for toplevel Transactions
Next
From: Tom Lane
Date:
Subject: Re: [WIP PATCH] Lazily assign xids for toplevel Transactions