On Mon, Dec 20, 2010 at 8:08 AM, Steve Kieu <[email protected]> wrote: > >> It isn't unusual for serialisation errors to be reported prior to >> commit: the database usually reports them as soon as it detects the >> problem. The traceback from the error you saw probably tells you >> where it occurred. Try wrapping your try/except block around the >> entire transaction logic rather than just the commit() call. >> >> If you're using PostgreSQL, the >> psycopg2.extensions.TransactionRollbackError exception should cover >> the cases you're interested in. >> > > Yes you are correct, I got the exception now if I wrap the entire block. > > Error I GOT YOU : could not serialize access due to concurrent update > > <class 'psycopg2.extensions.TransactionRollbackError'> > > Should I rollback and try again or just try to run the block again? It may > not improve the performance as I have to do it all again <sigh>
If your transaction fails, then none of the changes made during the transaction will have been recorded. So replaying the entire transaction is generally what you'd want to do. If you are performing many inserts or updates and want to maximise performance, you might be best off structuring your code so you can easily tweak how much work you do in each transaction. You can then adjust that setting to maximise the performance. Depending on what you're doing, updating 100 or 1000 rows in each transaction might be a good place to start. James. -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
