Re: locking problems - Mailing list pgsql-general

From Jonathan Ellis
Subject Re: locking problems
Date
Msg-id 005801c1ce38$f683ae80$0200000a@Jonathan
Whole thread Raw
In response to locking problems  ("Jonathan Ellis" <jbe@familyellis.org>)
Responses Re: locking problems
List pgsql-general
> Are you sure it's deadlocking?  I.e. it's rolling back because of
> "Deadlock detected" errors?

That's right.

> > How can a statement like this deadlock?  Doesn't it
> > acquire all necessary locks atomically?
>
> Yes.  The problem is in the case where another transaction is holding
> something on the table.  Postgres has a deadlock_timeout feature
> which is there to prevent clients from waiting forever.  What's yours
> set at?  Maybe you just need to set it higher.

I haven't changed this from the default (~20 seconds?).  Is it a strict
first-in-first-out queue?  Because there's a lot of other transactions
trying to update smaller portions of this table that seem to be cutting in
front of the line for the lock so to speak.

-Jonathan


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error
Next
From: pgsql-gen Newsgroup (@Basebeans.com)
Date:
Subject: Re: Postal code radius searches