From: | "Jonathan Ellis" <jbe(at)familyellis(dot)org> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: locking problems |
Date: | 2002-03-18 04:54:18 |
Message-ID: | 005801c1ce38$f683ae80$0200000a@Jonathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-gen Newsgroup (@Basebeans.com) | 2002-03-18 08:55:16 | Re: Postal code radius searches |
Previous Message | Tom Lane | 2002-03-18 02:24:54 | Re: cannot read block 39 of pg_attribute_relid_attnam_index: Input/output error |