Ok, thanks. I'll keep that in mind.
On Tue, Apr 1, 2014 at 7:45 PM, Andrew Sullivan <ajs@xxxxxxxxxxxxxxx> wrote:
On Tue, Apr 01, 2014 at 07:00:16PM -0400, Tom Lane wrote:I bet the case I was thinking of was the NOTIFY example. That never
> 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.
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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Si Chen
Open Source Strategies, Inc.
sichen@xxxxxxxxxxxxxxxxxxxxxxxx
http://www.OpenSourceStrategies.com
LinkedIn: http://www.linkedin.com/in/opentaps
Twitter: http://twitter.com/opentaps