Re: [HACKERS] ERROR: btree scan list trashed ??
От | Adriaan Joubert |
---|---|
Тема | Re: [HACKERS] ERROR: btree scan list trashed ?? |
Дата | |
Msg-id | 37A8530B.B40A5CC3@albourne.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] ERROR: btree scan list trashed ?? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] ERROR: btree scan list trashed ??
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: