Re: Should I implement DROP INDEX CONCURRENTLY?
От | Robert Haas |
---|---|
Тема | Re: Should I implement DROP INDEX CONCURRENTLY? |
Дата | |
Msg-id | CA+TgmobFn9VvAoOr4ucJvCUJfyWzjpi-n=9mi0JiszS2HDRYJw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should I implement DROP INDEX CONCURRENTLY? (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Fri, Feb 3, 2012 at 10:28 AM, Robert Haas <robertmhaas@gmail.com> wrote: > 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". I don't think this has been committed - does that mean you've decided against doing so, or just haven't had the round tuits? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: