Re: Clustering with minimal locking

From: "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: "Scott Ribe" <scott_ribe(at)killerbytes(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Clustering with minimal locking
Date: 2008-06-18 08:09:06
Message-ID: 65937bea0806180109m68bdb53cke3c74077f32d59ee@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Jun 18, 2008 at 9:26 AM, Decibel! <decibel(at)decibel(dot)org> wrote:

> On Jun 17, 2008, at 11:37 AM, Scott Ribe wrote:
>
>> BOOM! Deadlock.
>>>
>>
>> No more likely than with the current cluster command. Acquiring the lock
>> is
>> the same risk; but it is held for much less time.
>>
>
>
> Actually, no (at least in 8.2). CLUSTER grabs an exclusive lock before it
> does any work meaning that it can't deadlock by itself. Of course you could
> always do something like
>
> BEGIN;
> SELECT * FROM a;
> CLUSTER .. ON a;
> COMMIT;
>
> Which does introduce the risk of a deadlock

Really!!? Am I missing something? How can a single transaction, running
synchronous commands, deadlock itself!

Best regards,
--
gurjeet[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

Mail sent from my BlackLaptop device

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David 2008-06-18 08:43:25 Database design questions
Previous Message Cyril SCETBON 2008-06-18 08:01:51 Re: Error when trying to drop a tablespace