Tom Lane <tgl@sss.pgh.pa.us> schrieb:
>Andres Freund <andres@2ndquadrant.com> 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
>me
>>> 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
>in
>>> DefineIndex(), taking care to save snapshot->xmin before we destroy
>the
>>> 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
>if
>> 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
thewaiting is done...
Andres
---
Please excuse brevity and formatting - I am writing this on my mobile phone.