Bug List

Group OPT

GNATS 136 Only 64-bit platforms are supported. The issue is that lsns and some other data structures need atomic methods.

Group OPT

GNATS 143 The polyphase merge-sort does not handle this case: More than one run is required AND keys are embedded in objects AND the keys are already in lexicographic order in the object AND the keys are properly aligned AND the keys span multiple pages. It returns an error indication about a "broken key" comparison not being implemented. The workaround is to provide a marshal function or to put the sort key in the header of the object or to provide more memory (larger number of pages for the run size) for the sort.

Group OPT

GNATS 139 Convert w_assert9 to w_assert3 where the asserts are still reasonable and remove the rest. Some of these are obsolete, some are racy in the new mt-context. All the w_assert9's are what used to be w_assert3; they were turned into 9 to disable them until they could be evaluated for usefulness, and many have been converted to 2 or 3-level asserts; many remain to be addressed.

Page Implementation Notes

GNATS 157 The histoid_t heap should have some size limit (number of entries).

Page Implementation Notes

GNATS 116 Btree doesn't sort elements for duplicate keys in bulk-load. This is a problem inherited from the original SHORE storage manager.

Page Implementation Notes

GNATS 137 Latches can now be downgraded; btree code should use this.

Page Implementation Notes

GNATS 156 Btree SMOs during rollback can cause problems.

Page Implementation Notes

GNATS 49 (performance) There is no concurrent undo.

Page Implementation Notes

GNATS 47 In event of insertion failure, the hash table will have to be rebuilt with different hash functions, or will have to be modified in some way.

Page Implementation Notes

GNATS 35 The buffer manager hash table implementation contains a race. While a thread performs a hash-table lookup, an item could move from one bucket to another (but not from one slot to another within a bucket). The implementation contains a temporary work-around for this, until the problem is more gracefully fixed: if lookup fails to find the target of the lookup, it performs an expensive lookup and the statistics record these as bf_harsh_lookups. This is expensive.

Page Implementation Notes

GNATS 40 bf_m::upgrade_latch() drops the latch and re-acquires in the new mode, if it cannot perform the upgrade without blocking. This is an issue inherited from the original SHORE storage manager. To block in this case would enable a deadlock in which two threads hold the latch in SH mode and both want to upgrade to EX mode. When this happens, the statistics counter bf_upgrade_latch_race is incremented.

---