[ Oops, I missed the reply-to button the first time - sorry for the repeat, Csaba ] On 3/28/06, Csaba Nagy <nagy@xxxxxxxxxxxxxx> wrote: > > Try breaking down the A query with LIMIT/OFFSET so that it never holds > > locks for long. That way B will not wait for long, if at all, and will > > not fail. > > Just as a remark, this will only work if the chunks can be processed in > separate transactions. If the whole thing is related and A must be > completely wrapped in a transaction, then the locks placed by the first > queries will still hold until the end of the transaction... The current system we have is plain broken, as it has no transactions for anything, and we are getting bad results, occasionally. I'm not sure if it's possible to split A (the long running, non-interactive part) into multiple pieces. It starts first (if not, then there is no problem), and if a user comes along and does B, that needs to stomp on whatever A happened to be doing. It would probably be best if A just failed and rolled back at that point (it'll get run again in a few minutes, in any case). I looked at the concurrency bits of the manual on line, but I was getting the impression that B is the one that would potentially have problems if it tried to write while A was doing its business (reading and writing). Thankyou, -- David N. Welton - http://www.dedasys.com/davidw/ Linux, Open Source Consulting - http://www.dedasys.com/
