Yes you're right. It's the INSERT statement and not the DELETE statement that might fail if another transaction manages to execute and commit between the DELETE and INSERT of the first transaction (if read committed is being used). I somehow managed to wrap the wrong cursor.execute statement with an exception handler.
I've attached an updated version of the patch. Thanks, will apply and rebuild. Should we be thinking about setting backends to use full transactions instead of READ COMMITTED, as in set transaction ISOLATION LEVEL SERIALIZABLE ; perhaps only for such operations, but maybe for more? (I have no idea if this works in sqlite, and it seems even in PostgreSQL one can get phantom reads with SERIALIZABLE.)
pgpKn6y1voHIF.pgp
Description: PGP signature
