Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock?
От | Tom Lane |
---|---|
Тема | Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock? |
Дата | |
Msg-id | 14978.1366915821@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock? (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock?
|
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: