Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I am unsure if I should backpatch to 8.1: the code in cluster.c has
changed, and while it is relatively easy to modify the patch, this is a
rare bug and nobody has reported it in CLUSTER (not many people clusters
temp tables, it
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm not sure I follow. Are you suggesting adding a new function,
similar to pg_class_ownercheck, which additionally checks for temp-ness?
No, I was just suggesting adding the check for temp-ness in cluster()
and cluster_rel() where
Alvaro Herrera [EMAIL PROTECTED] writes:
I am unsure if I should backpatch to 8.1: the code in cluster.c has
changed, and while it is relatively easy to modify the patch, this is a
rare bug and nobody has reported it in CLUSTER (not many people clusters
temp tables, it seems). Should I patch
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm not sure I follow. Are you suggesting adding a new function,
similar to pg_class_ownercheck, which additionally checks for temp-ness?
No, I was just suggesting adding the check for temp-ness in cluster()
and cluster_rel() where we do
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
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
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).
Tom Lane wrote:
dx k9 [EMAIL PROTECTED] 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
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
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
Hi,
What would cause or what should I do with a table that hangs during its
reindexing? I can see in the messages the last table to reindex, so
sequentially the next table must be the problem.
I have statement_timeout set for 6 hours, then I get canceling statement
due to statement timeout
On Wed, 2007-05-02 at 09:50, dx k9 wrote:
Hi,
What would cause or what should I do with a table that hangs during its
reindexing? I can see in the messages the last table to reindex, so
sequentially the next table must be the problem.
I have statement_timeout set for 6 hours, then I get
Thanks for the response Scott.
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.
Too bad we can't come up with a -e parameter for exclude say,
Something like this
On Wed, 2007-05-02 at 10:49, dx k9 wrote:
Thanks for the response Scott.
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.
Too bad we can't come up with a -e
dx k9 [EMAIL PROTECTED] 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
13 matches
Mail list logo
