change id sequence getting reset to 0

[Kelly Campbell]

Our gerrit server got rebooted over the weekend, and after I restarted the gerrit service on it, we're seeing primary key issues while uploading new patchsets. As you can see, it went back to 1 for the change id. Subsequent calls get the next id. I couldn't find any known issues like this.

This is using gerrit 2.1.2.5 and mysql 5.0.51a


com.google.gwtorm.client.OrmException: insert failure on patch_set_ancestors
       at com.google.gwtorm.schema.sql.SqlDialect.convertError(SqlDialect.java:122)
       at com.google.gwtorm.jdbc.JdbcAccess.convertError(JdbcAccess.java:331)
       at com.google.gwtorm.jdbc.JdbcAccess.doInsert(JdbcAccess.java:178)
       at com.google.gwtorm.jdbc.JdbcAccess.doInsert(JdbcAccess.java:35)
       at com.google.gwtorm.client.impl.AbstractAccess.insert(AbstractAccess.java:56)
       at com.google.gerrit.server.git.ReceiveCommits.insertAncestors(ReceiveCommits.java:1535)
       at com.google.gerrit.server.git.ReceiveCommits.createChange(ReceiveCommits.java:818)
       at com.google.gerrit.server.git.ReceiveCommits.createNewChanges(ReceiveCommits.java:767)
       at com.google.gerrit.server.git.ReceiveCommits.onPreReceive(ReceiveCommits.java:238)
       at org.eclipse.jgit.transport.ReceivePack.executeCommands(ReceivePack.java:797)
       at org.eclipse.jgit.transport.ReceivePack.service(ReceivePack.java:540)
       at org.eclipse.jgit.transport.ReceivePack.receive(ReceivePack.java:486)
       at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.java:71)
       at com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.java:94)
       at com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.java:34)
       at com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.java:65)
       at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.java:376)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
       at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
       at java.util.concurrent.FutureTask.run(FutureTask.java:166)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
       at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
       at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.java:315)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
       at java.lang.Thread.run(Thread.java:636)
Caused by: java.sql.BatchUpdateException: Duplicate entry '1-1-1' for key 1
       at com.mysql.jdbc.PreparedStatement.executeBatchSerially(PreparedStatement.java:2007)
       at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1443)
       at com.google.gwtorm.jdbc.JdbcAccess.execute(JdbcAccess.java:293)
       at com.google.gwtorm.jdbc.JdbcAccess.doInsert(JdbcAccess.java:171)
       ... 23 more

[Shawn Pearce]

On Mon, Jun 14, 2010 at 12:46, Kelly Campbell <kel...@google.com> wrote:
> Our gerrit server got rebooted over the weekend, and after I restarted the
> gerrit service on it, we're seeing primary key issues while uploading new
> patchsets. As you can see, it went back to 1 for the change id. Subsequent
> calls get the next id. I couldn't find any known issues like this.
> This is using gerrit 2.1.2.5 and mysql 5.0.51a

Its a known issue with the MySQL implementation.

http://code.google.com/p/gerrit/issues/detail?id=518

To fix it for now, you'll need to do something like:

SELECT MAX(change_id) + 1 FROM changes;
INSERT INTO change_id VALUES (...that value...);

For each of the _id tables in your database, and their corresponding
data tables.