Re: [HACKERS] ERROR: btree scan list trashed ??
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] ERROR: btree scan list trashed ?? |
Дата | |
Msg-id | 7332.933947463@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] ERROR: btree scan list trashed ?? (Adriaan Joubert <a.joubert@albourne.com>) |
Список | pgsql-hackers |
Adriaan Joubert <a.joubert@albourne.com> writes: > OK, I've dropped my user-defined type index and it hasn't made any > difference. I've had quite a few of the following again: > UPDATE TasksIds SET qstate=8::bit1 where task=358 and id=5654 > ERROR: btree scan list trashed; can't find 0x1401744a0 > I've got a lot of logging switched on, and these do not seem to be > preceded by errors. Since patching it the system seems to recover ok, so > I'm wondering whether this could be a caching issue. I think I will just > lock all tables in their entirety now, and see whether that fixes it > (there goes my MVCC performance boost 8-(). I still think it has > something to do with concurrent access to the indices. Let us know whether going to full locking makes any difference. I am currently wondering whether this is a porting issue (64-bit vs 32-bit pointers). If it only happens on 64-bit platforms, that would explain why we haven't seen many similar reports. Unfortunately, that theory provides little useful guidance about where to look :-( regards, tom lane
В списке pgsql-hackers по дате отправления: