Bug List

Class w_hash_t< T, LOCK, K >

(GNATS 114, non-critical performance issue) improve these hash funcs. This is used in: histograms, dirty page table for restart.

Group LOGSPACE

GNATS 142 There remain a number of places in the storage manager code that react to a lack of log space with a fatal error; this is a hold-over from the original storage manager, before any attempt to reserve space was in place. This code has to be rewritten to handle more gracefully such errors. In order for this to be done, the multi-threaded transaction support will be deprecated.

Group OPT

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

Page Implementation Notes

GNATS 127: Larger page sizes are broken. We temporarily support only 8KB pages.

Page Implementation Notes

GNATS 138 (performance) The allocation of space for records is known to have performance problems and this portion of the storage manager needs redesign. This is a problem inherited from the original SHORE storage manager.

Page Implementation Notes

GNATS 33 (performance) t_compact is turned off. It is expensive and has not been tested lately, thus there is presently no policy that will keep files compact. If files become too sparse, the server must reorganize the database.

Page Implementation Notes

GNATS 129 There is a gap between the end of the top-level action and the logging of the file-page allocation during which a crash could cause a page to be allocated but unformatted. This needs to be fixed; the fix is to support undoable-compensation log records so that the log insert and the compensation can be done in one operation. The issue is in handling these records on restart.

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 49 (performance) There is no concurrent undo.

Page Implementation Notes

bf_core_m::htab 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.

---