From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Brendan Duddridge <brendan(at)clickspace(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: App very unresponsive while performing simple update |
Date: | 2006-05-31 15:11:41 |
Message-ID: | 20060531151141.GA20992@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, May 31, 2006 at 01:23:07 -0500,
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> wrote:
> On Sun, May 28, 2006 at 07:20:59PM -0400, Greg Stark wrote:
> > Brendan Duddridge <brendan(at)clickspace(dot)com> writes:
> > More likely you were blocking on some lock. Until that other query holding
> > that lock tries to commit Postgres won't actually detect a deadlock, it'll
> > just sit waiting until the lock becomes available.
>
> Wow, are you sure that's how it works? I would think it would be able to
> detect deadlocks as soon as both processes are waiting on each other's
> locks.
I don't see how it could wait for a commit. If a command is blocked waiting for
a lock, how are you going to get a commit (you might get a rollback if the
query is aborted)?
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-05-31 15:24:05 | Re: App very unresponsive while performing simple update |
Previous Message | Jan de Visser | 2006-05-31 12:34:44 | Re: App very unresponsive while performing simple update |