On 2014-11-14 02:04:00 -0600, Jim Nasby wrote: > On 11/13/14, 3:50 PM, Andres Freund wrote: > Having been responsible for a site where downtime was a 6 figure > dollar amount per hour, I've spent a LOT of time worrying about lock > problems. The really big issue here isn't grabbing an exclusive lock; > it's grabbing one at some random time when no one is there to actively > monitor what's happening. (If you can't handle *any* exclusive locks, > that also means you can never do an ALTER TABLE ADD COLUMN either.)
> With that in mind, would it be possible to set this up so that the > time-consuming process of building the new index file happens first, > and then (optionally) some sort of DBA action is required to actually > do the relfilenode swap? I realize that's not the most elegant > solution, but it's WAY better than this feature not hitting 9.5 and > people having to hand-code a solution. I don't think having a multi step version of the feature and it not making into 9.5 are synonymous. And I really don't want to make it even more complex before we have the basic version in. I think a split like your: > Possible syntax: > REINDEX CONCURRENTLY -- Does what current patch does > REINDEX CONCURRENT BUILD -- Builds new files > REINDEX CONCURRENT SWAP -- Swaps new files in could make sense, but it's really an additional feature ontop. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers