From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Dave Cramer" <pg(at)fastcrypt(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Postgres General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: deadlock while re-indexing table |
Date: | 2008-02-12 18:02:52 |
Message-ID: | 873arynjcj.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Dave Cramer" <pg(at)fastcrypt(dot)com> writes:
> On 12-Feb-08, at 10:37 AM, Tom Lane wrote:
>
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>> Dave Cramer wrote:
>>>> reindex table user_profile;
>>>> ERROR: deadlock detected
>>>> DETAIL: Process 32450 waits for AccessExclusiveLock on relation
>>>> 194689112 of database 163880909; blocked by process 31236.
>>>> Process 31236 waits for AccessShareLock on relation 194689110 of
>>>> database 163880909; blocked by process 32450.
>>
>>> I don't find this very surprising ... I would suggest using "reindex
>>> index" for each index instead. I'm not sure if REINDEX TABLE is
>>> supposed to be deadlock-free.
>>
>> It's not guaranteed to be so, but I'd think simple cases would be
>> okay. What's that other process doing?
>>
> The other process is inserting into the user_profile table.
Hm. This shouldn't be enough to cause a deadlock. Both inserts and reindex use
the same method to get the list of indexes which returns them in the same
order.
Did either transaction do anything else in the same transaction previously?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2008-02-12 18:14:13 | Re: deadlock while re-indexing table |
Previous Message | Dave Cramer | 2008-02-12 17:31:05 | Re: deadlock while re-indexing table |