On Sat, 27 Nov 2004, Tom Lane wrote:
> > In my case deadlock happens between two identical statements executed
> > from different transactions and they have the same execution plan(index
> > scan on one attribute - 'color' in schema I presented).
>
> That's a bit hard to believe; once the rows are
Kamil Kaczkowski <[EMAIL PROTECTED]> writes:
>>> You're mistaken; it takes a row lock on each row it updates. I'm not
>>> sure why the two UPDATEs are visiting the same rows in different orders,
>>> but if they do the failure is certainly possible.
>>
>> One of them could be using an indexscan wh
On Sat, 27 Nov 2004, Alvaro Herrera wrote:
> > You're mistaken; it takes a row lock on each row it updates. I'm not
> > sure why the two UPDATEs are visiting the same rows in different orders,
> > but if they do the failure is certainly possible.
>
> One of them could be using an indexscan while
On Sat, Nov 27, 2004 at 12:58:36PM -0500, Tom Lane wrote:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> > Well, there has to be something, since an UPDATE in Read Committed mode
> > simply doesn't have any locks that can deadlock.
>
> You're mistaken; it takes a row lock on each row it up
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Well, there has to be something, since an UPDATE in Read Committed mode
> simply doesn't have any locks that can deadlock.
You're mistaken; it takes a row lock on each row it updates. I'm not
sure why the two UPDATEs are visiting the same rows
On Sat, Nov 27, 2004 at 03:40:11PM +0100, Kamil Kaczkowski wrote:
> > It's not the locking on the UPDATE that's getting you. Multiple updates
> > can run concurrently (depending on your serialization level anyway, I'm
> > talking about default setup here).
> >
> > Where the problem is is the foreig
On Sat, 27 Nov 2004, Martijn van Oosterhout wrote:
> On Sat, Nov 27, 2004 at 03:20:16AM +0100, Kamil Kaczkowski wrote:
> > > Change things so you don't need to update more than one row per query,
> > > perhaps? The lack of any primary key on that table was already pretty
> > > disturbing from a d
On Sat, Nov 27, 2004 at 03:20:16AM +0100, Kamil Kaczkowski wrote:
> > Change things so you don't need to update more than one row per query,
> > perhaps? The lack of any primary key on that table was already pretty
> > disturbing from a database-theory point of view. Maybe you should
> > rethink
On Fri, 26 Nov 2004, Tom Lane wrote:
> > My understanding was that row-level lock at UPDATE statement is somehow
> > atomic and it locks all rows matched at once.
>
> Nope.
>
> > But what's the solution? How can I force UPDATEs to lock rows in the same
> > order? There's no ORDER BY clause for UPD
Kamil Kaczkowski <[EMAIL PROTECTED]> writes:
>> Another possible explanation is if the UPDATE
>> command can update more than one row --- in that case different backends
>> might happen to reach the target rows in different orders.
> Yes, this UPDATE changes several rows, I didn't know this can be
On Fri, 26 Nov 2004, Tom Lane wrote:
> Kamil Kaczkowski <[EMAIL PROTECTED]> writes:
> > I have problems with deadlocks caused by(at least I think so) row-level
> > locks and I can't find the reason.
>
> The failure seems clearly a deadlock on row-level locks. Are you
> certain you've removed all
Kamil Kaczkowski <[EMAIL PROTECTED]> writes:
> I have problems with deadlocks caused by(at least I think so) row-level
> locks and I can't find the reason.
The failure seems clearly a deadlock on row-level locks. Are you
certain you've removed all relevant FKs (those pointing to the table
as well
Hello.
I'm running postgresql 7.4.6 on linux 2.4.21(Redhat Enterpise 3).
I have problems with deadlocks caused by(at least I think so) row-level
locks and I can't find the reason.
First I thought this has something with fk constraints, but removing it didn't
change anything.
Here is simplified sch
13 matches
Mail list logo
