This is not a proposal, just an attempt to summarize.

It was noticed that generators were flaky in V6. Investigation
showed that the source of the problem was an incorrect computation
of the number of generators that could be stored on a generator
page.

Originally, generators were 32 bits long, which made them a lot
like pointer pages, which contain 32 bit page numbers. Pointer
pages also contain two bit indicators of the fill level of the
page, so they actually use 34 bits per entry. InterBase computes
the number of things per page for a variety of page types -
pointer pages, transaction inventory pages, page information pages...

The algorithm to find a generator is to divide the generator
number by the number of generators that can exist on a page
to get the position of the page in the list of generator pages,
and use the remainder as the offset into that page.

So far so good. However, rather than compute and carry around
the actual number of generators that can fit on a page, the
coder of the algorithm just used a number that happened to be
hanging around, assuming it was the number of pointers per
pointer page, and therefor good enough.

Not so good when the size of generators doubled.

Even less good since the number used was not actually pointers
per pointer page, but page information bits per page information
page. Since the page information page (PIP) contains one bit
per page (allocated/not allocated), there was a 32 to 1 degree
of optimism in the number of generators per page.

The problem exists in earlier versions. Any database with
a 1K page size and more than 250 generators will write
generators 251 to 8000 in random space. It's more acute in
V6, because the problem starts at about 117 (? why not 126 -
writing into the space reserved for fill bits on a pointer
page wouldn't hurt, would it?)

Is this approximately right?

Ann