Issue 2034: com.google.gwtorm.server.OrmConcurrencyException: Concurrent modification detected
Status:  Released
Owner: ----
Closed:  Jul 2014
Reported by sp3...@gmail.com, Jul 25, 2013
************************************************************
***** NOTE: THIS BUG TRACKER IS FOR GERRIT CODE REVIEW *****
***** DO NOT SUBMIT BUGS FOR CHROME, ANDROID, INTERNAL *****
***** ISSUES WITH YOUR COMPANY'S GERRIT SETUP, ETC.    *****
***** THOSE ISSUE BELONG IN DIFFERENT ISSUE TRACKERS!  *****
************************************************************

Affected Version:
v2.6.1, with cherry-pick strategy configured

What steps will reproduce the problem?
1. push a change for a branch
2. review it
3. try to submit it

What is the expected output? What do you see instead?
Expected output is status 'Merged'. I see 'Submitted, Merge pending' and exception in logs instead.

Please provide any additional information below.

[2013-07-25 08:26:27,600] ERROR com.google.gerrit.server.git.ChangeMergeQueue : Merge attempt for repo,refs/heads/stable-1.0 failed
com.google.gerrit.server.git.MergeException: Cannot merge 426ee90165b910d6dc7ed3c0e262fb227befc8ce
        at com.google.gerrit.server.git.CherryPick._run(CherryPick.java:124)
        at com.google.gerrit.server.git.SubmitStrategy.run(SubmitStrategy.java:99)
        at com.google.gerrit.server.git.MergeOp.preMerge(MergeOp.java:382)
        at com.google.gerrit.server.git.MergeOp.merge(MergeOp.java:287)
        at com.google.gerrit.server.git.ChangeMergeQueue$2.call(ChangeMergeQueue.java:207)
        at com.google.gerrit.server.git.ChangeMergeQueue$2.call(ChangeMergeQueue.java:204)
        at com.google.gerrit.server.util.RequestScopePropagator$5.call(RequestScopePropagator.java:222)
        at com.google.gerrit.server.util.RequestScopePropagator$4.call(RequestScopePropagator.java:201)
        at com.google.gerrit.server.git.PerThreadRequestScope$Propagator$1.call(PerThreadRequestScope.java:75)
        at com.google.gerrit.server.git.ChangeMergeQueue.mergeImpl(ChangeMergeQueue.java:204)
        at com.google.gerrit.server.git.ChangeMergeQueue.merge(ChangeMergeQueue.java:124)
        at com.google.gerrit.server.change.Submit.apply(Submit.java:111)
        at com.google.gerrit.server.change.Submit.apply(Submit.java:53)
        at com.google.gerrit.httpd.restapi.RestApiServlet.service(RestApiServlet.java:288)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
        at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:263)
        at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:178)
        at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:62)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.gwtexpui.server.CacheControlFilter.doFilter(CacheControlFilter.java:70)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:64)
        at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:57)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:75)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
        at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
        at org.eclipse.jetty.server.Server.handle(Server.java:365)
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
        at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:937)
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:998)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:856)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
        at java.lang.Thread.run(Thread.java:679)
Caused by: com.google.gwtorm.server.OrmConcurrencyException: Concurrent modification detected
        at com.google.gwtorm.jdbc.JdbcAccess.execute(JdbcAccess.java:440)
        at com.google.gwtorm.jdbc.JdbcAccess.updateAsBatch(JdbcAccess.java:261)
        at com.google.gwtorm.jdbc.JdbcAccess.update(JdbcAccess.java:214)
        at com.google.gerrit.server.git.CherryPick.writeCherryPickCommit(CherryPick.java:168)
        at com.google.gerrit.server.git.CherryPick._run(CherryPick.java:84)
        ... 59 more


Then later on:

[2013-07-25 08:27:06,524] ERROR com.google.gerrit.server.git.ChangeMergeQueue : Merge attempt for repo,refs/heads/stable-1.0 failed
com.google.gerrit.server.git.MergeException: Cannot merge 426ee90165b910d6dc7ed3c0e262fb227befc8ce
        at com.google.gerrit.server.git.CherryPick._run(CherryPick.java:124)
        at com.google.gerrit.server.git.SubmitStrategy.run(SubmitStrategy.java:99)
        at com.google.gerrit.server.git.MergeOp.preMerge(MergeOp.java:382)
        at com.google.gerrit.server.git.MergeOp.merge(MergeOp.java:287)
        at com.google.gerrit.server.git.ChangeMergeQueue$2.call(ChangeMergeQueue.java:207)
        at com.google.gerrit.server.git.ChangeMergeQueue$2.call(ChangeMergeQueue.java:204)
        at com.google.gerrit.server.util.RequestScopePropagator$5.call(RequestScopePropagator.java:222)
        at com.google.gerrit.server.util.RequestScopePropagator$4.call(RequestScopePropagator.java:201)
        at com.google.gerrit.server.git.PerThreadRequestScope$Propagator$1.call(PerThreadRequestScope.java:75)
        at com.google.gerrit.server.git.ChangeMergeQueue.mergeImpl(ChangeMergeQueue.java:204)
        at com.google.gerrit.server.git.ChangeMergeQueue.merge(ChangeMergeQueue.java:124)
        at com.google.gerrit.server.change.Submit.apply(Submit.java:111)
        at com.google.gerrit.server.change.Submit.apply(Submit.java:53)
        at com.google.gerrit.httpd.restapi.RestApiServlet.service(RestApiServlet.java:288)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
        at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:263)
        at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:178)
        at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:62)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.gwtexpui.server.CacheControlFilter.doFilter(CacheControlFilter.java:70)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.gerrit.httpd.AllRequestFilter$FilterProxy$1.doFilter(AllRequestFilter.java:64)
        at com.google.gerrit.httpd.AllRequestFilter$FilterProxy.doFilter(AllRequestFilter.java:57)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.gerrit.httpd.RequestContextFilter.doFilter(RequestContextFilter.java:75)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:163)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.FilterDefinition.doFilter(FilterDefinition.java:168)
        at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:58)
        at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:118)
        at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:113)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1307)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:453)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
        at org.eclipse.jetty.server.Server.handle(Server.java:365)
        at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
        at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:937)
        at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:998)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:856)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
        at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
        at java.lang.Thread.run(Thread.java:679)
Caused by: com.google.gwtorm.server.OrmDuplicateKeyException: patch_set_ancestors
        at com.google.gwtorm.schema.sql.DialectPostgreSQL.convertError(DialectPostgreSQL.java:58)
        at com.google.gwtorm.jdbc.JdbcAccess.convertError(JdbcAccess.java:448)
        at com.google.gwtorm.jdbc.JdbcAccess.insert(JdbcAccess.java:160)
        at com.google.gerrit.server.git.CherryPick.insertAncestors(CherryPick.java:206)
        at com.google.gerrit.server.git.CherryPick.writeCherryPickCommit(CherryPick.java:164)
        at com.google.gerrit.server.git.CherryPick._run(CherryPick.java:84)
        ... 59 more
Caused by: java.sql.BatchUpdateException: Batch entry 0 INSERT INTO patch_set_ancestors(ancestor_revision,change_id,patch_set_id,position)VALUES('bff0df1ba821152332bf7b2220b6988c494c3d60','23827','2','1') was aborted.  Call getNextException to see the cause.
        at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2621)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1837)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:407)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2754)
        at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
        at org.apache.commons.dbcp.DelegatingStatement.executeBatch(DelegatingStatement.java:297)
        at com.google.gwtorm.schema.sql.SqlDialect.executeBatch(SqlDialect.java:370)
        at com.google.gwtorm.jdbc.JdbcAccess.execute(JdbcAccess.java:438)
        at com.google.gwtorm.jdbc.JdbcAccess.insertAsBatch(JdbcAccess.java:202)
        at com.google.gwtorm.jdbc.JdbcAccess.insert(JdbcAccess.java:155)
        ... 62 more
Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "patch_set_ancestors_pkey"
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2103)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
        ... 70 more


I managed to workaround it by manually dropping duplicate entries from DB. Then after restart gerrit was able to merge it correctly.
Jul 30, 2013
#1 sp3...@gmail.com
Note to self because I hit it again: drop related entries from patch_sets and patch_sets_ancestors (can be found by patch_set_id). Gerrit merges submitted changes with 5 min interval.
Oct 2, 2013
#2 phil.hord
We were hit by this exact problem, also on v2.6.1 and also using cherry-pick commits.  We also use Postgresql (may be related).

Extra symptom:  Each failed attempt to reconcile by Gerrit (every 5 minutes) caused a new duplicate patchset to be recorded.  After four days there were over 1000 patchsets for the one commit.

It seems to have resolved itself when the original developer examined the patch in Gerrit.  Maybe he submitted it again.  We're not sure.  But the status changed to "Merged", the patch log shows it was merged at that time, and the cycle abated.  I did not mess with gsql at all.

The patch log says this when I merged it:

    Phil Hord Sep 26 6:47 PM
    Patch Set 2: Code-Review+2

And it says this four days later when the problem finally was (mysteriously) resolved:

    Phil Hord Sep 30 7:18 AM
    Change has been successfully cherry-picked as 480cb8a5ee5270879bc8ec3a00b30d9269fc03d1


The commit shows this:

  commit 480cb8a5ee5270879bc8ec3a00b30d9269fc03d1
  Author:     removed
  AuthorDate: Fri Sep 20 11:09:29 2013 -0400
  Commit:     Phil Hord <removed>
  CommitDate: Thu Sep 26 18:54:32 2013 -0400

    ...

    Change-Id: I9eb70d7b5a259f7ed2e2c35a406a94c7a3294402
    Reviewed-on: https://gerrit-server/gerrit/5662
    Tested-by: Jenkins <removed>
    Reviewed-by: Phil Hord <removed>


So, the merge completed Monday morning when the developer examined the patch, but the commit was cherry-picked successfully (with review notes inserted) four days earlier (Thursday).

I see exceptions every 5 minutes in the error log exactly like the reported ones.  The SHA-1 they are complaining about is not the SHA-1 for this commit which received 1000+ extra patchsets.  Instead it is another commit I tried to merge about a minute later, and neither is dependent on the other.

The very first exception is different from the rest.  It says

    [2013-09-26 18:53:45,809] ERROR com.google.gerrit.server.git.ChangeMergeQueue : Merge attempt for iptv/module/tasker,refs/heads/master failed
    com.google.gerrit.server.git.MergeException: Cannot merge 90710c4edbd2e0522a8935009d77cc2c000db934
    ...
    Caused by: com.google.gwtorm.server.OrmConcurrencyException: Concurrent modification detected


But all the subsequent exceptions say: 

    [2013-09-30 00:05:13,018] ERROR com.google.gerrit.server.git.ChangeMergeQueue : Merge attempt for iptv/module/tasker,refs/heads/master failed
    com.google.gerrit.server.git.MergeException: Cannot merge 90710c4edbd2e0522a8935009d77cc2c000db934
    ...
    Caused by: com.google.gwtorm.server.OrmDuplicateKeyException: patch_set_ancestors


Notice the CommitDate coincides with the first exception (Concurrent modification), not the last one (patch_set_ancestors).

Oct 2, 2013
#3 casta...@motorola.com
Ditto all of that except the 1000 duplicate patchset.
Oct 2, 2013
#4 phil.hord
Update: The commit which received 1000+ extra patchsets was NOT cherry-picked into the master branch as Gerrit claimed.  The head of the master branch was not updated.

A different commit was submitted (4 days later) and it became the new head of 'master'; this is the mysterious action which caused the exceptions to abate.  Once this occurred, no more exceptions appeared in the log, no more patchsets appeared on the "lost" commit, and the "lost" commit was marked as "merged" even though it was never merged into master.

This is bad.  Worse than I expected.


Oct 2, 2013
#5 casta...@motorola.com
In our case I think we can work around the corruption usually with a fresh patchset or by direct push to refs/heads (and we abandon the workflow).

Our issue is that we cannot stop the concurrent modifications.  They keep happening.  And every time they do we subsequently start getting index errors.  It has been happening for a while but it has increased in frequency since we upgraded to 2.6.1.
Nov 11, 2013
Project Member #6 dougk....@gmail.com
Also reproduced on 2.7 with PostgreSQL.  Like the original poster, I removed the duplicate entries through the DB and had the author resubmit the patchset, and the second try, it merged cleanly.  I'm wondering if this might be resolved by executing the database section of writeCherryPickCommit() in a transaction.  This would at least allow the partial changes to the database to rollback and not get us in this bad state...
Dec 13, 2013
Project Member #7 bruce.zu@sonymobile.com
> xecuting the database section of writeCherryPickCommit() in a transaction.  This would at least allow the partial changes to the database to rollback and not get us in this bad state...

please see https://gerrit-review.googlesource.com/#/c/53080/2

Feb 21, 2014
#8 l...@diamand.org
I'm still seeing this with 2.8.1.

Caused by: com.google.gwtorm.server.OrmConcurrencyException: Concurrent modification detected
        at com.google.gwtorm.jdbc.JdbcAccess.execute(JdbcAccess.java:440)
        at com.google.gwtorm.jdbc.JdbcAccess.updateAsBatch(JdbcAccess.java:261)
        at com.google.gwtorm.jdbc.JdbcAccess.update(JdbcAccess.java:214)
        at com.google.gerrit.server.git.CherryPick.writeCherryPickCommit(CherryPick.java:169)
        at com.google.gerrit.server.git.CherryPick._run(CherryPick.java:84)

Apr 14, 2014
#9 nthieb...@gmail.com
Still seen this with 2.8.3
Apr 30, 2014
#10 Ian.Kuml...@gmail.com
Still a issue in 2.8.4..
Apr 30, 2014
Project Member #11 dougk....@gmail.com
The patch Bruce mentioned was merged into the 2.9 branch, so its benefits won't be realized until then.  Also, if I'm not mistaken, the only thing the writeCherryPickCommit() change will accomplish will be preventing the subsequent "duplicate primary key" errors -- the "concurrent modification detected" in some ways is bound to happen -- we just don't want to be in an inconsistent state afterwards.
Apr 30, 2014
#12 schniede...@gmail.com
I see the same issue consistently for every patchset for one specific repository (I'm blocked on this), and occasionally for other repositories (where a resubmit usually fixes it).
This is on 2.8.3 with MySQL.
Jun 11, 2014
#13 davidtw...@gmail.com
I am still seeing this issue with 2.9-rc2, which includes Bruce's change. A commit gets stuck in status:submitted, and others get stuck in that state until the first one is abandoned. For the changes that aren't abandoned, it looks like they become submitted with regard to the database, but the latest patchset is not merged into the repo. This is a critical blocking issue for us right now.

Jun 12, 2014
Project Member #14 David.Os...@gmail.com
https://gerrit-review.googlesource.com/57770
Status: ChangeUnderReview
Jun 12, 2014
Project Member #15 David.Os...@gmail.com
See also related issue [1] and this discussion on mailing list [2].

The problem seems to be that automatic merging jobs that
Gerrit schedules per default every 5 min. interfere with manual
scheduled merge job. So the unit test that reproduces the reported exception
simulate that collision by setting automatic job scheduling frequency to 1 second.

For that collision to happen,the manual and automatic merge attempt must
coincidently happen at the same time. This would explain why only 1.6% of all
changes are corrupt.

Until this change is reviewed/merged/released there is a workaround:

Shut down automatic merge job scheduling by setting:

  changeMerge.checkFrequency = 0

in gerrit.config.

Another preventive measure would be to define unique index as proposed in this change [3]
Obviously, database must be first cleaned up from duplicate rows in patch_sets table.

[1] https://code.google.com/p/gerrit/issues/detail?id=2702
[2] https://groups.google.com/forum/#!topic/repo-discuss/kKrhagOOqSk
[3] https://gerrit-review.googlesource.com/57784
Jun 12, 2014
Project Member #16 David.Os...@gmail.com
(No comment was entered for this change.)
Labels: -Priority-Minor Priority-Major
Jun 12, 2014
Project Member #17 David.Os...@gmail.com
OK, can reproduce the problem on master, PostgreSQL & project with cherry-pick submit type.

Here are the steps:

0/ check out/build/deploy most recent master (21a1f790e749ec5b70619880987bf0946e8a038b)
1/ set up PostgreSQL
2/ set up new project with submit type cherry-pick
3/ adjust gerrit.config to simulate earlier collision between background and manual merge scheduling:

[changeMerge]
   checkFrequency = 1s

4/ apply this change [1], or define unique index manually:
CREATE UNIQUE INDEX patch_sets_byChangeRev ON patch_sets (change_id, revision);

5/ set up bash script to create/push/approve/submit 1000 of changes:

$ for i in {1..1000}; do git pull -r; echo "$i" >> README; git add README; git commit -m "ps $i"; git push gerritd HEAD:refs/for/master; ssh gerritd gerrit review --code-review=2 --submit "$i,1" ; done

6/ Verify that unique constraint violation exception occurs [2]

7/ Verify that database corruption was prevented [3]

[1] https://gerrit-review.googlesource.com/57784
[2] http://paste.openstack.org/show/83883
[3] http://paste.openstack.org/show/83888

Jun 14, 2014
Project Member #18 David.Os...@gmail.com
 Issue 2246  has been merged into this issue.
Jul 25, 2014
Project Member #20 David.Os...@gmail.com
(No comment was entered for this change.)
Status: Released
Labels: FixedIn-2.8
Sep 21, 2015
#21 moej...@gmail.com
Still seeing this issue in 2.9.4. Was there any work around or fix that could reliably stop it from reoccurring?