process-accepted conflicts with some rosetta job

Relevant traceback.

wishlist since we can live with it for now and the fix is outside soyuz scope.

Celso Providelo wrote:
> Private bug reported:
>
> I't only happened once but was frustrating, process-accepted explodes on
> psycopg programming error (could not serialize operation).

Serialization exceptions are normal and have to be handled, or you need to
use a lower transaction isolation level. Most likely all that needs doing is
  pass 'isolation=READ_COMMITTED' through to your initZopeless call, as you
rarely need the data consistency guaranteed by the serializable transaction
isolation level.

http://www.postgresql.org/docs/current/static/transaction-iso.html

 subscribe stub

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Thank you, stub.

I'll do some tests with READ_COMMITTED isolation level in mawson and see how it behaves.

Should I expect performance improvemements as well ?

Celso Providelo wrote:

> Should I expect performance improvemements as well ?

Nope. Possibly a slow down, but that might just be rumour ;)

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Today it happened again, exactly the same issue, could make it work some time later.

happened again .... nothing done yet.

This will happen with high loads in Rosetta imports and right now we are doing the initialization of Edgy.

This just caused cron.daily to fail, costing us an hour out of the tight schedule for 6.10 beta.

If there is an intensive Rosetta job running, I ask that it please be delayed until after the release. If not, perhaps this bug is more common than it is supposed.

It just happened a second time. We are unable to publish any packages in edgy now, and this is blocking all development including the preparation of the beta release.

My attempts to run cron.daily are failing consistently despite repeated attempts. I suspect there is a Rosetta job running somewhere, but I have no means to find out more.

James H. has suggested talking with stub when he wakes up.

poimport was running. for future reference it runs as launchpad on gangotri.

On an unrelated note, why is this bug marked private?

We generally flag launchpad bugs private when they contain tracebacks, non-trivial code snippets or database schema descriptions to avoid leaking proprietary information. There is a line that when we cross causes people to freak and we don't quite know where that line is, so I tend to err on the side of caution.

The patch for fixing the Soyuz part goes attached.

Stub, can you please do a quick review for me ?

Soyuz part of the fix is landed in RF 4103

Used the same solution as soyuz

I got a problem with my merge, so it's not yet merged..

The code is in rocketfuel now.

soyuz part released some time ago