Re: Should I implement DROP INDEX CONCURRENTLY?
От | Robert Haas |
---|---|
Тема | Re: Should I implement DROP INDEX CONCURRENTLY? |
Дата | |
Msg-id | CA+TgmoYJ8o8ZT=K=4STR1uNvebYzuP2==FuN2Xn-C_YiTMvfOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should I implement DROP INDEX CONCURRENTLY? (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Should I implement DROP INDEX CONCURRENTLY?
|
Список | pgsql-hackers |
On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >> On sön, 2012-01-29 at 22:01 +0000, Simon Riggs wrote: >>> Patch now locks index in AccessExclusiveLock in final stage of drop. >> >> Doesn't that defeat the point of doing the CONCURRENTLY business in the >> first place? > > That was my initial reaction. > > We lock the index in AccessExclusiveLock only once we are certain > nobody else is looking at it any more. > > So its a Kansas City Shuffle, with safe locking in case of people > doing strange low level things. Yeah, I think this is much safer, and in this version that doesn't seem to harm concurrency. Given our previous experiences in this area, I wouldn't like to bet my life savings on this having no remaining bugs - but if it does, I can't find them. I'll mark this "Ready for Committer". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: