Ok, thanks. I'll keep that in mind.
On Tue, Apr 1, 2014 at 7:45 PM, Andrew Sullivan <a...@crankycanuck.ca> wrote: > On Tue, Apr 01, 2014 at 07:00:16PM -0400, Tom Lane wrote: > > > one of the clients, in a way that isn't visible to the deadlock detector. > > One way for that to happen without any external interconnections is if > the > > client is waiting for a NOTIFY that will never arrive because the > would-be > > sender is blocked. > > I bet the case I was thinking of was the NOTIFY example. That never > occurred to me as an explanation, but now that you mention it, it > seems quite likely to me. > > More generally (and for the OP's problem), my experience is that lots > of updates against the same rows in an unpredictable order is an > excellent way to run into trouble, and long-running transactions are a > major source of these problems. Without a more detailed report about > what is going on in the present case, I don't think it's going to be > possible to diagnose better than has been done. > > A > > -- > Andrew Sullivan > a...@crankycanuck.ca > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Si Chen Open Source Strategies, Inc. sic...@opensourcestrategies.com http://www.OpenSourceStrategies.com LinkedIn: http://www.linkedin.com/in/opentaps Twitter: http://twitter.com/opentaps
