[Tickets #13876] Re: horde_histories_modseq reset to 1 by code

noreply at bugs.horde.org noreply at bugs.horde.org
Mon Feb 23 18:12:38 UTC 2015


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13876
------------------------------------------------------------------------------
  Ticket             | 13876
  Updated By         | horde at albasoft.com
  Summary            | horde_histories_modseq reset to 1 by code
  Queue              | Synchronization
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


horde at albasoft.com (2015-02-23 18:12) wrote:

I guess you make "manually inserting keys" when carrying out migration  
of databases. On a daily use, you don't have to make manual inserts in  
a sequence controlled column, as sequence is up to date by its own.  
Maybe you can check if a "manual insert" on primary key is being done,  
before calling resetPkSequence.

I think the problem with history_modseq reset must be a call to  
resetPkSequence when horde_history_modseq table was empty (no rows at  
all).
Your code would then reset primary key to '1'. Is this right?

But this table can be empty if enough processes are running at the  
same time. Function _nextModSeq at "Horde/History/Sql.php" makes  
inserts and also deletes:
...
$result = $this->_db->insert('INSERT INTO horde_histories_modseq  
(history_modseqempty) VALUES(0)');
$this->_db->delete('DELETE FROM horde_histories_modseq WHERE  
history_modseq <> ?', array($result));
...

One process may have $result==3, and will delete others row.
A second one may have $result==4, and will delete the previous one.
Now horde_history_modseq table can be empty.
And a third process can be making a call to resetPkSequence just by  
then, finding no data at all and reseting sequence to '1'.

In my database, just before the reset, there are two login errors in  
horde_histories with the very same timestamp and consecutive modseq  
values (the highest value before the reset). Maybe those events  
cleaned  horde_history_modseq table while a third process was calling  
resetPkSequence.





More information about the bugs mailing list