From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nathan Wilhelmi <wilhelmi(at)ucar(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Deferred constraints and locks... |
Date: | 2008-02-13 15:15:20 |
Message-ID: | 47B30988.3070905@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/12/2008 3:04 PM, Tom Lane wrote:
> Nathan Wilhelmi <wilhelmi(at)ucar(dot)edu> writes:
>> Hello - Trying to track down a lock contention problem, I have a process
>> that does a series of select / insert operations. At some point the
>> process grabs a series of RowExclusiveLock(s) and has the obvious effect
>> of stalling other processes. I logged all the statements and don't see
>> any for update or explicit lock statements.
>
> Insert statements would naturally take RowExclusiveLock, but that
> doesn't block other DML operations. So the question is what *else*
> are you doing?
Those SELECT statements aren't by chance FOR UPDATE, are they?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
From | Date | Subject | |
---|---|---|---|
Next Message | Hermann Muster | 2008-02-13 15:19:09 | Order of SUBSTR and UPPER in statement |
Previous Message | Andrew Sullivan | 2008-02-13 15:12:29 | Re: SELECT CAST(123 AS char) -> 1 |