Re: [HACKERS] Simultaneous index creates on different schemas cause deadlock?
От | anarazel@anarazel.de |
---|---|
Тема | Re: [HACKERS] Simultaneous index creates on different schemas cause deadlock? |
Дата | |
Msg-id | 7a255af4-951e-4c97-b02b-00eacc3644ce@email.android.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Simultaneous index creates on different schemas cause deadlock? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Simultaneous index creates on different schemas cause deadlock?
|
Список | pgsql-admin |
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.
В списке pgsql-admin по дате отправления: