Project Specification

Project Definition and Technical Approach

The aim of this release is to fix memory growth in the 5.0 InterBase server as experienced by some of our customers . While we are at it, we will also fix bugs that cause server crashes. This will also include updated documentation and the latest version of the InterClient driver. The version number of this product will be 5.1.1

Project Definition

  • Summary of end-user visible structure of the proposed project: no major changes from InterBase 5.0 except: a change to isql and wisql to reflect the SQL Role functionality, providing an undocumented feature to monitor memory usage, and a new version of InterClient
  • Major feature sets: fix bugs related to memory growth in InterBase 5.0 (mandatory): bug numbers 7647, 7556, 7907, 8752, 8754, 8757, 8772, 8781.
  • fix the following issues which qualify as minor functionality (for which there are no bug numbers):
  • The case of server exiting when we run out of room in the lock manager.
  • Adding (undocumented) functionality to monitor memory usage in InterBase. Memory Trace Functional Specification
  • Fix IB client side memory leaks found by BDE customers.
  • Handling out of memory conditions by providing appropriate error messages.
  • Fix server crash/data corruption bugs (high priority): 8640, 8732, 8812, 8725
  • fix SQL bug (nice to have): 4840 Bug 4840 Functional Specification
  • fix SQL Role relates bugs (nice to have): 8729, 8734, 8749
  • other misc. bugs (nice to have): 7995, plus recent server crash bug posted on the list server

Technical Approach

The design of memory growth bugs was done on a as-needed-basis to fix problems encountered by certain customers. Some of the major design changes include:

  • Adding a switch in the config file to turn on monitoring memory usage.
  • Free up memory associated with prepared/allocated dsql statements on the server when the attachment goes away. (see problem resolution for bug 8781).
  • Changing the size of a memory block in gds_alloc from 1024 to 1032. Every memory pool request to gds_alloc() was being rounded off to integral multiples of 1024 + 8 bytes (for header info.) and when the pools were being released to the gds memory allocator, it was found that a large number of 1024 bytes blocks were left around that could not be used (unless they were merged with other blocks). Now all memory allocations will be in integral multiples of 1032, thus the left over blocks will also be 1032 bytes long, which get reused. This cuts down the memory wasted in our memory allocation pool.
  • Fix bug in the pipelining part of the client. This was causing the client to ask for the next batch of requests too fast, thus causing the server to consume memory by storing unnecessarily too many the requests. This shows up prominently in doing a select from a large table (of the order of a million rows) and in backing up such large tables using gbak.
  • Fix bug in looper (bug 8640): The looper would (before this bug fix) cause the stack to overflow due to unnecessarily heavy recursion when handling errors. (See problem resolution for bug 8640)
  • Bug 4840. Though this was a bug, its fix involved major changes to the various parts of the code base that it warrants a mention here. See the Bug 4840 Functional Specification and Bug 4840 Design Specification for this bug fix.