From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] ERROR: btree scan list trashed ?? |
Date: | 1999-08-06 13:51:03 |
Message-ID: | 7332.933947463@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Adriaan Joubert <a(dot)joubert(at)albourne(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-08-06 13:52:47 | Re: [HACKERS] 6.5.2 |
Previous Message | Vadim Mikheev | 1999-08-06 09:59:38 | 6.5.2 |