Ticket #2308 (closed defect: worksforme)
change classification fallback to update fails on postgres
|Reported by:||dustin||Owned by:|
Harry sent along the traceback and logs, and I had a look.
I think what's happening here is that the same change is classified by the same scheduler twice, as suggested as a possibility in
master/buildbot/schedulers/basic.py 148 # NOTE: this may double-call gotChange for changes that arrive just as 149 # the scheduler starts up. In practice, this doesn't hurt anything.
It looks like postgres is aborting the transaction after the first failed query, which is annoying but known:
dustin=# begin; BEGIN dustin=# insert into foo values (1); INSERT 0 1 dustin=# insert into foo values (1); ERROR: duplicate key value violates unique constraint "foo_d_key" dustin=# update foo set d=2; ERROR: current transaction is aborted, commands ignored until end of transaction block }} I suspect that this can be fixed by ending the transaction and starting a new one. But, we should be revealing this problem with some tests, first.