From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: locks in CREATE TRIGGER, ADD FK |
Date: | 2005-03-23 03:03:26 |
Message-ID: | 200503230303.j2N33Q813031@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway wrote:
> So I think it should be possible to lock both the heap relation and the
> index with ExclusiveLock, which would allow SELECTs on them. This would
> apply to both the single relation and multiple relation variants of
> CLUSTER (since we do each individual clustering in its own transaction).
>
> ... except that when we rebuild the relation's indexes, we acquire an
> AccessExclusiveLock on the index. This would introduce the risk of
> deadlock. It seems necessary to acquire an AccessExclusiveLock when
> rebuilding shared indexes, since we do the index build in-place, but I
> think we can get by with an ExclusiveLock in the non-shared case, for
> similar reasons as above: we build the new index and then swap relfilenodes.
Certainly we need to upgrade to an exclusive table lock to replace the
heap table. Do we want to get a shared lock and possibly starve waiting
for an exclusive lock on the table to swap the new one in? Do we do
such escallation anywhere else?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-03-23 03:12:24 | Re: locks in CREATE TRIGGER, ADD FK |
Previous Message | Neil Conway | 2005-03-23 02:55:53 | Re: locks in CREATE TRIGGER, ADD FK |