Tom Lane <> schrieb:

>Andres Freund <> writes:
>> On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
>>> Since we know that C.I.C. executes in its own transaction, and there
>>> can't be more than one on the same table due to locking, it seems to
>>> that it'd be safe to drop our own snapshot before waiting for other
>>> xacts to end.  That is, we could just rearrange the last few steps
>>> DefineIndex(), taking care to save snapshot->xmin before we destroy
>>> snapshot so that we still have that value to pass to
>>> GetCurrentVirtualXIDs().
>>> Anybody see a flaw in that solution?
>> Except that it still will unnecessarily wait for other CICs, just not
>> deadlock, I don't see a problem. We could have a PROC_IN_CIC flag or
>> something so we can ignore other index creations, but I am not sure
>> its worth the complication.
>I'm not sure it's a good idea to ignore other CICs altogether --- they
>could be executing user-defined index functions that do strange things
>like consult other tables.  Since this seems to me to be a bit outside
>the intended use-case for CIC anyway, I think it's good enough if they
>just don't deadlock

Fine with me, especially as nobody seems to have complained so far other than 
the OP, so it doesn't seem to be to common. 
I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY has a 
similar problem? Depends a bit on how the waiting is done...


Please excuse brevity and formatting - I am writing this on my mobile phone.

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to