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.
If anybody has any more suggestions of what I could try, please let me
know.
Cheers,
Adriaan