A.M. Kuchling schrieb:
> The completely untested patch below should remedy the occasional
> exceptions that PyPI is occasionally raising. Can someone provide a
> sanity check for this patch? (I'm not going to deploy it -- not
> familiar enough with the setup on the live site.)
I don't understand why this is necessary (although I trust that these
exceptions really occur).
Can any expert on Postgres please shed a light on it? The code currently
reads
self.cursor.execute("lock table browse_tally")
if self.is_cache_current():
# overlapping update, just release the lock
self.store.commit()
return
self.cursor.execute("delete from browse_tally")
...
self.cursor.execute("update timestamps set value=now() where
name='browse_tally'")
self.store.commit()
Now, this code gets an exception
psycopg.ProgrammingError: ERROR: could not serialize access due to
concurrent update
delete from browse_tally
How is that possible? This code is the only code code updating
browse_tally (although multiple simultaneous processes may run the
same code); I would expect that the "lock table" statement prevents
concurrent updates.
Any help appreciated.
Regards,
Martin
_______________________________________________
Catalog-sig mailing list
Catalog-sig@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
