Ann Harrison wrote:

>
> 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?
>

Right, Ann. It should be about 125 64-bit generators since the control
bit space has been used to store and maintain valid generators. I
neglected to transition from 116 to 125 (250 for 32-bit gens) in my tale
after I revealed the second bug concerning the bad data page/pointer
page constant.

This also means that any existing, valid generators 126-250 in a V5.6
database have been lost in the backup/restore to V6 (again assuming a
1KB page).

Regards,
Charlie