| 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: | Whole Thread | Raw Message | 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 |