| Subject | Re: [firebird-support] Generator values corrupt on restore |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-01-18T08:35:47Z |
At 08:52 AM 18/01/2005 +0200, you wrote:
far-negative as you can go without you head popping out of your tummy
button. When the generator tries to get the "next" number it bumps into
"no-can-do" and reinvents itself as zero. (This is also what's supposed to
happen when a generator gets "used up" -- for anyone that lives that long.)
Since this is the second time a question similar to this one has come up, I
decided to have a play with it myself (fiddle with a metadata-only backup)
and demonstrate that generating the next number on "that number" actually
doesn't overflow OR roll over. It generates the next higher number.
Therefore I begin to smell a rodent. That piece of biblical lore regarding
what happens when generators roll over comes from the misty times when
generators were integers. What I sniff is that --just possibly-- we are
looking at the twos-complement not of the lowest possible Int64 but the
lowest possible integer. Which would be a bug that will bite the
unsuspecting (not to mention producing extraordinarily big numbers for
primary keys in fresh young databases!!)
Since any numbers longer than a phone-number all look the same to me
("big") I don't know how to tell anyone how to play around with the
twos-complement of that number and arrive at zero.
However, it looks worth mentioning in Firebird-devel for a "please explain"
- or leaving it here for a day or two for Ann to look at...
In the meantime, if you like, just run a script that sets all your
generators to zero and then you can start pumping in your data.
./heLen
> >>Firebird 1.5.2Nope, I don't think that's how it would be, since the actual number is as
> >>
> >>when I do a database restore all my generator values are set to
> >>18267668493213428
> >>Any idea why?
> >
> > It's the representation (twos-complement or something like that) of the
> > lowest possible negative 64-bit integer. The first time a number is
> > generated from it, the generator will "roll over" to zero and generate 1
> > (or whatever number the call to Gen_ID dictates).
>
>So what you are saying is that 18267668493213428 + 1 = 0?
far-negative as you can go without you head popping out of your tummy
button. When the generator tries to get the "next" number it bumps into
"no-can-do" and reinvents itself as zero. (This is also what's supposed to
happen when a generator gets "used up" -- for anyone that lives that long.)
Since this is the second time a question similar to this one has come up, I
decided to have a play with it myself (fiddle with a metadata-only backup)
and demonstrate that generating the next number on "that number" actually
doesn't overflow OR roll over. It generates the next higher number.
Therefore I begin to smell a rodent. That piece of biblical lore regarding
what happens when generators roll over comes from the misty times when
generators were integers. What I sniff is that --just possibly-- we are
looking at the twos-complement not of the lowest possible Int64 but the
lowest possible integer. Which would be a bug that will bite the
unsuspecting (not to mention producing extraordinarily big numbers for
primary keys in fresh young databases!!)
Since any numbers longer than a phone-number all look the same to me
("big") I don't know how to tell anyone how to play around with the
twos-complement of that number and arrive at zero.
However, it looks worth mentioning in Firebird-devel for a "please explain"
- or leaving it here for a day or two for Ann to look at...
In the meantime, if you like, just run a script that sets all your
generators to zero and then you can start pumping in your data.
./heLen