Re: simple update query stuck

From: Si Chen <sichen(at)opensourcestrategies(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: simple update query stuck
Date: 2014-04-02 22:51:11
Message-ID: CAAYSSjOWp=HpcMJQJ+asFpSF1hRdOn9dXWSTjv-dHU8CFSidPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ok, thanks. I'll keep that in mind.

On Tue, Apr 1, 2014 at 7:45 PM, Andrew Sullivan <ajs(at)crankycanuck(dot)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
> ajs(at)crankycanuck(dot)ca
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

--
Si Chen
Open Source Strategies, Inc.
sichen(at)opensourcestrategies(dot)com
http://www.OpenSourceStrategies.com
LinkedIn: http://www.linkedin.com/in/opentaps
Twitter: http://twitter.com/opentaps

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2014-04-02 22:56:08 Re: SSD Drives
Previous Message Rob Sargent 2014-04-02 22:46:06 Re: COPY v. java performance comparison