The issue can be replicated with rapid parallel calls. E.g. two instances of:

while ./devtools/fakehub --no-commit getRPMChecksums 102; do echo; done

(the new arg was added to fakehub to facilitate this)

Fine for now, but maybe we should do something like this directly in BatchInsertProcessor to sanitize more similar issues? It could be unnecessary load in some cases but better safe than sorry.

but maybe we should do something like this directly in BatchInsertProcessor

I don't think it should sort automatically unless the the caller requests it. Exactly /how/ to sort would vary by situation anyway. We could add a sort option, but I doubt it would result in any less invocation code. All we had to do here was add a sorted().

For that matter, I don't really think this call really needed to use BulkInsertProcessor. Two inserts is hardly "bulk".

Now we can get (as expected)

xmlrpc.client.Fault: <Fault 1: '<class \'psycopg2.errors.UniqueViolation\'>: duplicate key value violates unique constraint "rpm_checksum_pkey"\nDETAIL:  Key (rpm_id, sigkey, checksum_type)=(3, , 0) already exists.\n'>

during parallel computation. Not sure if it is worth handling.

Ah, yes, I didn't get that because of the --no-commit, but of course it would happen. Could switch this to an upsert, or use a savepoint.

The latter issue can be replicated by running while ./devtools/fakehub getRPMChecksums 102; do echo; done in parallel (as above, but without the --no-commit) while repeatedly deleting the db entry (delete from rpm_checksum where rpm_id=102;).

Commit d0de5852 fixes this pull-request