| 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: | Whole Thread | Raw Message | 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
| 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 |