On Tue, 20 Mar 2001, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > DROP TABLE temptest;
> > + NOTICE: FlushRelationBuffers(temptest, 0): block 0 is referenced (private 0, global 1)
> > + ERROR: heap_drop_with_catalog: FlushRelationBuffers returned -2
> > SELECT * FROM temptest;
> >> Hoo, that's interesting ... Exactly what fileset were you using again?
> > When you say 'fileset', I'm assuming you are referring to the --schedule
> > parameter --
> No, I was wondering about whether you had an inconsistent set of source
> files, or had managed to not do a complete rebuild, or something like
> that. The above error should be entirely impossible considering that
> the table in question is a temp table that's not been touched by any
> other backend. If you did manage to get this from a clean build then
> I think we have a serious problem to look at.
Standard RPM rebuild -- always wipes the whole build tree out and re-expands
from the tarball, reapplies patches, and rebuilds from scratch every time I
change even the smallest detail in the spec file -- which is why it takes so
long to get these things out. So, no, this is a scratch build from a fresh
tarball.
> Does anyone else have time to try to duplicate the problem tonight?
> If it's replicatable at all, I think it's a release stopper.
I have not yet been able to repeat the problem. I am running my fifth
regression test run (which takes a long time on this P133) with a freshly
initdb'ed PGDATA -- the previous regression runs were done on the same PGDATA
tree as the first run was done on. Took 12 minutes 40 seconds, but I can't
repeat the error. I'm hoping it was a problem on my machine -- educate me on
what caused the error so I can see if something in my setup did something not
so nice. So, the score is one error out of six test runs, thus far.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11