Tom Lane wrote:
>
> Adriaan Joubert <a.joubert@albourne.com> writes:
> >> What Postgres version are you using, and on what platform? If it's
> >> anything older than 6.5.1, an upgrade would probably be a good idea.
>
> > Sorry, I should have mentioined that. I'm using 6.5.0 on DEC Alpha
> > (Digital Unix, compiled with cc).
>
> Alpha, eh? We have some known porting problems on 64-bit architectures,
> and I wonder whether this is one of them. Going to be hard to nail that
> down until we can reproduce the error, however.
>
> After some digging around in backend/access/nbtree/nbtscan.c, which is
> producing the error, I notice that the routine in question is searching
> a list that does not get cleared properly at transaction abort. It's
> not clear that that's the cause of the error message, though. What
> I suggest at this point is that you pay more attention to what happens
> just before the transaction in which you get the "btree scan list
> trashed" message. In particular, are there any commands that abort
> with errors a little bit earlier in the same backend? It might take
> the combination of an error in a btree-index-using command and then
> another btree index access to provoke the "trashed" symptom.
That may be it. I have some PL routines that raise an exception if an
operation could lead to an inconsistency in my database tables. This is
not really an error, but I do want to abort the transaction in that
case, so I raise an exception. I'll continue trying to nail it down and
then I can look with the debugger what happens.
BTW, I've installed 6.5.1 and still have the same problems. Vacuuming
hung up everything, and I had to shut the whole thing down and restart
it to get it working again. Dropping the indices and rebuilding them all
fixed the problem.
How difficult is it to clear the list at transaction abort? Is this
something I could patch and try out?
Thanks a lot for looking at this, much appreciated!
Adriaan
