php-general Digest 28 Jun 2013 21:56:02 -0000 Issue 8281
Topics (messages 321515 through 321517):
Re: Reseting the auto-increment number in a MySQL database.
321515 by: adriano
321516 by: Paul M Foster
321517 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
holes in sequence of auto increment happen using transaction for insert
new record but you don't commit transaction itself
it seems that the autoincrement is incremented anyway
at least this is my case.
--- End Message ---
--- Begin Message ---
On Thu, Jun 27, 2013 at 11:47:28PM +0200, adriano wrote:
>
> holes in sequence of auto increment happen using transaction for
> insert new record but you don't commit transaction itself
> it seems that the autoincrement is incremented anyway
> at least this is my case.
I think what Tedd was referring to was something else. The "hole" was
quite large. I've seen this behavior myself, in PostgreSQL. From one
transaction to the next, there were over 10,000 skipped numbers, and
only me and my wife on the system. Some sort of bug, like a spinlock
that wasn't interrupted the way it should have been. I remember the
system taking forever to calm down before it gave the next transaction a
number way forward of the last one. I waited in front of my browser for
quite some time. But I couldn't explain why.
Paul
--
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com
--- End Message ---
--- Begin Message ---
On Jun 27, 2013, at 8:47 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
> On Thu, Jun 27, 2013 at 11:47:28PM +0200, adriano wrote:
>
>> holes in sequence of auto increment happen using transaction for
>> insert new record but you don't commit transaction itself
>> it seems that the autoincrement is incremented anyway
>> at least this is my case.
>
> I think what Tedd was referring to was something else. The "hole" was
> quite large. I've seen this behavior myself, in PostgreSQL. From one
> transaction to the next, there were over 10,000 skipped numbers, and
> only me and my wife on the system. Some sort of bug, like a spinlock
> that wasn't interrupted the way it should have been. I remember the
> system taking forever to calm down before it gave the next transaction a
> number way forward of the last one. I waited in front of my browser for
> quite some time. But I couldn't explain why.
>
> Paul
Yes, it was something like what Paul said -- it was not a transaction skip.
I don't know what to think about it -- no explanation.
But, the problem suddenly vanished -- very strange.
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
